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;
From:   Felipe Gasper <felipe@felipegasper.com>
Content-Type: text/plain;
        charset=utf-8
Content-Transfer-Encoding: 8BIT
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Supplementary GIDs?
Message-Id: <4A964428-65EA-49D4-B7B4-35D22D89D418@felipegasper.com>
Date:   Sat, 23 Jul 2022 11:53:55 -0400
To:     linux-nfs@vger.kernel.org
Precedence: bulk

Hello,

	I’m seeing two different behaviours between kernel NFS server versions in AlmaLinux 8 and Ubuntu 20. The following Perl demonstrates the issue:

--------
perl -MFile::Temp -Mautodie -Mstrict -e'my $fh = File::Temp::tempfile( DIR => "/the/nfs/mount" ); my $mailgid = getgrnam "mail"; my ($uid, $gid) = (getpwnam "bin")[2,3]; chown $uid, $gid, $fh; $) = "$gid $mailgid"; $> = $uid; chown -1, $mailgid, $fh'
--------

	What this does, as root, is:

1) Creates a file under /mnt, then deletes it, leaving the Linux file descriptor open.

2) chowns the file to bin:bin.

3) Sets the process’s EUID & GUID to bin & bin/mail.

4) Does fchown( fd, -1, mailgid ).

	When the server is AlmaLinux 8, the above works. When the server is Ubuntu 20, it fails with EPERM. (The client is AlmaLinux 8 in both cases.) Both are configured identically.

	Does anyone know of anything that changed fairly recently in the kernel’s NFS server that might affect this? I’ve done a packet capture and confirmed that in both cases there’s an NFS SETATTR sent in an RPC 2.4 packet whose UID & GIDs match the process.

	Thank you in advance!

cheers,
-Felipe