> On Jul 23, 2022, at 11:53 AM, Felipe Gasper <felipe@xxxxxxxxxxxxxxxx> 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? On on the NFS client, can you show us the output of 'nfsstat -m' during each test run? > 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 -- Chuck Lever
