access(2) inaccurately reports execute permissions

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::[email protected]: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  [email protected]
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

I hate to say this, but I think there have been some relevant changes since then, is it possible to retry with a more recent kernel?

Other things worth trying:

- watch the traffic in wireshark, check that the ACCESS calls on the wire agree with what your test program is seeing.
- to verify that your server is mapping to the correct user, try touching a new file after su'ing and acquiring kerberos credentials, and check who the new file is owned by.

--b.

If it's fixed, that's great. I won't be able to try a newer kernel for a while.

Looks like the server response is OK:

NFS 234 V4 Reply (Call In 36) ACCESS, [Access Denied: MD XT], [Allowed: RD XE]

root@radio:/testmnt# ./runas -k test314 touch tmp/foobar
root@radio:/testmnt# ls -l tmp/foobar
-rw-rw---- 1 test314 user-test314 0 Mar  8 18:14 tmp/foobar

John