I have evidence that the system call access(2), with mode set to X_OK, does not accurately report execute permissions for a file mounted via NFS4 and with execute provided by an NFS4 acl. Here's a transcript: root@radio:/testmnt# nfs4_getfacl acltestjan3017/testacls/f.test301.test261.400.u+test314=5 A::OWNER@:rtTcCy A::test314@xxxxxxxxxxxx:rxtcy A::GROUP@:tcy A::EVERYONE@:tcy root@radio:/testmnt# ./runas -k test314 ./test_access acltestjan3017/testacls/f.test301.test261.400.u+test314=5 USER 999999314 (test314) 999999314 (test314) 999999314 (test314) GROUP 1427981 (user-test314) 1427981 (user-test314) 1427981 (user-test314) KRB5 test314@xxxxxxxxxxxx SUPPL GROUPS: user-test314 r-- acltestjan3017/testacls/f.test301.test261.400.u+test314=5 root@radio:/testmnt# ./runas -k test314 acltestjan3017/testacls/f.test301.test261.400.u+test314=5 My script "runas" su's and acquires kerberos credentials for the given user, and executes the given command. My command test_access (a c program) prints all process credentials and then runs access(2) separately with R_OK, W_OK and X_OK modes, and prints the result. The second line shows that access(2) indicates that user test314 has only read rights, despite the user ACE for test314. The last line shows that test314 can, in fact, execute the file (which is empty - no error). My client is a Debian Jessie system with these various versions of things: Debian 8.6 Kernel 3.16.0-4-amd64 acl 2.2.52-2 libgssapi-krb5-2 1.12.1+dfsg-19+deb8u2 librpcsecgss3 (not installed) nfs-utils (? don't see it) util-linux 2.25.2-6 The server is an EMC Isilon. John -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
