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;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: Supplementary GIDs?
From:   Felipe Gasper <felipe@felipegasper.com>
In-Reply-To: <869F67CA-812C-4A39-A36E-390EE68241B4@felipegasper.com>
Date:   Mon, 25 Jul 2022 13:02:15 -0400
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: 8BIT
Message-Id: <FFDC7E05-26B6-4C3A-9A08-28EB7E2877D7@felipegasper.com>
References: <4A964428-65EA-49D4-B7B4-35D22D89D418@felipegasper.com>
 <7CE7A3E4-118D-4CB0-A952-5DC0014A0882@oracle.com>
 <869F67CA-812C-4A39-A36E-390EE68241B4@felipegasper.com>
To:     Chuck Lever III <chuck.lever@oracle.com>
Precedence: bulk


> On Jul 25, 2022, at 09:29, Felipe Gasper <felipe@felipegasper.com> wrote:
> 
> 
> 
>> On Jul 25, 2022, at 09:23, Chuck Lever III <chuck.lever@oracle.com> wrote:
>> 
>> 
>> 
>>> On Jul 23, 2022, at 11:53 AM, Felipe Gasper <felipe@felipegasper.com> wrote:
>>> 
>>> 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.
>> 
>> On each NFS sever, can you run 'uname -a' and show us the output?
> 
> Ubuntu 20 (the “bad” one):
> root@kvm-demo-support:~# uname -a
> Linux kvm-demo-support 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> 
> AlmaLinux 8 (the “good” one):
> [root@10-2-71-6 ~]# uname -a
> Linux 10-2-71-6.cprapid.com 4.18.0-372.16.1.el8_6.x86_64 #1 SMP Wed Jul 13 03:56:16 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
> 
>> 
>> On on the NFS client, can you show us the output of 'nfsstat -m'
>> during each test run?
> 
>> nfsstat -m
> /mnt/phil from kvm-demo-support.dev.cpanel.net:/volumes/kvm-demo
> Flags:	rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.2.65.75,local_lock=none,addr=10.0.32.83
> 
> /mnt/felipe from 10.2.71.6:/home
> Flags:	rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.2.65.75,local_lock=none,addr=10.2.71.6

Update on this: it appears to have been a result of Ubuntu 20’s /etc/default/nfs-kernel-server’s containing `RPCMOUNTDOPTS="--manage-gids"`. Once I commented that line out the issue went away. I also confirmed that AlmaLinux 8 doesn’t enable `--manage-gids`. The varlink traffic in the Ubuntu server to/from rpc.mountd showed that it was asking systemd for the user’s groups and getting an empty response.

Sorry for the noise, and thank you for your time.

cheers,
-Felipe