faccessat and AT_SYMLINK_NOFOLLOW

[Nick Kralevich <nnk@google.com>]

In some sense, this is a continuation of the earlier thread at
http://www.openwall.com/lists/musl/2014/09/25/1 . That thread is the
only concrete discussion I can find describing the intended behavior
of faccessat and AT_SYMLINK_NOFOLLOW

I'm working on a modification to Android's libc for faccessat.
Currently, in Android's libc, faccessat() completely ignores any flags
argument, and just passes through the call to the kernel (dropping the
flags field).

I've proposed a modification to Android's libc to implement
AT_SYMLINK_NOFOLLOW (https://android-review.googlesource.com/128582).
By calling access() on /proc/self/fd/FDNUM, where FDNUM was created
using open(O_PATH | O_NOFOLLOW), we can ask the kernel to make an
access control decision on the symlink itself. The model was suggested
by Rich in https://sourceware.org/bugzilla/show_bug.cgi?id=14578
(although that was for a different bug).

However, as I've digged into this more, I'm more and more confused
about what the correct behavior should be for
faccessat(AT_SYMLINK_NOFOLLOW).

Imagine the following code:

  symlink("foo.is.dangling", "foo");
  if (faccessat(AT_FDCWD, "foo", R_OK, AT_SYMLINK_NOFOLLOW) == 0) {
    int fd = openat(AT_FDCWD, "foo", O_RDONLY | O_NOFOLLOW);
  }

For glibc, faccessat(AT_NOFOLLOW) will return true, since the symlink
exists and the permissions on the symlink allow access. (Symlinks on
Linux are always 777, so glibc considers any symlink to be globally
accessible)

However, the openat() call will fail, since the target is a symlink.

It seems to me that, if faccessat(R_OK, AT_SYMLINK_NOFOLLOW) returns
true, than the openat() should succeed (absent race conditions).
Similarly, if faccessat() returns false, then the openat() should
fail. To do so otherwise seems counter-intuitive to me.

I'm curious what others think the appropriate behavior of
faccessat(AT_SYMLINK_NOFOLLOW) should be. Clearly the glibc behavior
here is wrong, but I'm not sure what the right behavior should be...

-- 
Nick Kralevich | Android Security | nnk@google.com | 650.214.4037