Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 19 Feb 2022 12:34:12 +0100
From:   Christian Brauner <brauner@kernel.org>
To:     "suy.fnst@fujitsu.com" <suy.fnst@fujitsu.com>
Cc:     "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "l@damenly.su" <l@damenly.su>,
        "brauner@kernel.org" <brauner@kernel.org>
Subject: Re: [bug?] nfs setgid inheritance
Message-ID: <20220219113412.7ov4tbkisv4vnmo3@wittgenstein>
References: <OS3PR01MB770539462BE3E7959DAF8B5789389@OS3PR01MB7705.jpnprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <OS3PR01MB770539462BE3E7959DAF8B5789389@OS3PR01MB7705.jpnprd01.prod.outlook.com>
Precedence: bulk

On Sat, Feb 19, 2022 at 08:34:30AM +0000, suy.fnst@fujitsu.com wrote:
> Hi NFS folks,
>   During our xfstests, we found generic/633 fails like:
> ============================================
> FSTYP         -- nfs
> PLATFORM      -- Linux/x86_64 btrfs 5.17.0-rc4-custom #236 SMP PREEMPT Sat Feb 19 15:09:03 CST 2022
> MKFS_OPTIONS  -- 127.0.0.1:/nfsscratch
> MOUNT_OPTIONS -- -o vers=4 127.0.0.1:/nfsscratch /mnt/scratch
> 
> generic/633 0s ... [failed, exit status 1]- output mismatch (see /root/xfstests-dev/results//generic/633.out.bad)
>     --- tests/generic/633.out   2021-05-23 14:03:08.879999997 +0800
>     +++ /root/xfstests-dev/results//generic/633.out.bad 2022-02-19 16:31:28.660000013 +0800
>     @@ -1,2 +1,4 @@
>      QA output created by 633
>      Silence is golden
>     +idmapped-mounts.c: 7906: setgid_create - Success - failure: is_setgid
>     +idmapped-mounts.c: 13907: run_test - Success - failure: create operations in directories with setgid bit set
>     ...
>     (Run 'diff -u /root/xfstests-dev/tests/generic/633.out /root/xfstests-dev/results//generic/633.out.bad'  to see the entire diff)
> Ran: generic/633
> Failures: generic/633
> Failed 1 of 1 tests
> ============================================
> 
> The failed test is about setgid inheritance. 
> When  a file is created with S_ISGID in the directory with S_ISGID, 
> NFS  doesn't strip the  setgid bit of the new created file but others
> (ext4/xfs/btrfs) do.  They call inode_init_owner() which does
> the strip after new_inode().
> However, NFS has its own logical to handle inode capacities. 
> As the test says the behavior can be filesystem type specific,
> I'd report to you NFS guys and ask whether it's a bug or not?

Thanks for the report. I'm not sure why NFS would have different rules
for setgid inheritance. So I'm inclined to think that this is simply a
bug similar to what we saw in xfs and ceph. But I'll let the NFS folks
determine that.

XFS is only special in so far as it has a sysctl that lets it alter sgid
inheritance behavior. And it only has that to allow for legacy irix
semantics iiuc.

Christian