Subscribe

Setuid not working without read access in NFSv4

Hi,

I'm having issues with setuid/setgid programs after upgrade (move to c-DOT) from NFSv3 to NFSv4 access protocol.

Apparently, programs with "setuid/setgid" bit set work as they should only when also "read" permission is set on the executable file. That's different from NFSv3, where setuid bit only without read access on file is enough to execute.

I have the same volume mounted once through NFSv3 and once using NFSv4 (parallel NFS):

[testuser@edud01sap02 ~]$ mount|grep NFS

vssaptest5001:/vssaptest5001_edu_bench1 on /mnt-NFSv3 type nfs (rw,vers=3,addr=10.243.66.50)

vssaptest5001:/vssaptest5001_edu_bench1 on /mnt-NFSv4 type nfs (rw,vers=4,minorversion=1,addr=10.243.66.50,clientaddr=10.243.66.62)

The access rights:

[testuser@edud01sap02 ~]$ ls -l /mnt-NFSv3/setuidtest

-r-s--s---. 1 otheruser otheruser 7018 Aug 16 19:31 /mnt-NFSv3/setuidtest

[testuser@edud01sap02 ~]$ ls -l /mnt-NFSv4/setuidtest

-r-s--s---. 1 otheruser otheruser 7018 Aug 16 19:31 /mnt-NFSv4/setuidtest

I got "permission denied" error when trying to execute through NFSv4:

[testuser@edud01sap02 ~]$ /mnt-NFSv4/setuidtest

-bash: /mnt-NFSv4/setuidtest: Permission denied

... while the same file executes correctly through NFSv3:

[testuser@edud01sap02 ~]$ /mnt-NFSv3/setuidtest

uid=555 euid=666

gid=555 egid=666

When I set the read access bit for group owner, the program executes also through NFSv4:

[testuser@edud01sap02 ~]$ sudo chmod g+r /mnt-NFSv4/setuidtest

[testuser@edud01sap02 ~]$ ls -l /mnt-NFSv4/setuidtest

-r-sr-s---. 1 otheruser otheruser 7018 Aug 16 19:31 /mnt-NFSv4/setuidtest

[testuser@edud01sap02 ~]$ /mnt-NFSv4/setuidtest

uid=555 euid=666

gid=555 egid=666

Is this something what has changed since NFSv3 or do I miss some configuration? This is an 8.2.1 c-DOT system with SetUID option enabled in export-policy:

Honor SetUID Bits in SETATTR: true

This behaviour prevents our systems from executing programs which do have strict access mode validation hardcoded to perform before proceeding with execution. Therefore just adding that "read" permission is not a valid workaround for me.

Best regards,

Lukas