[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150205203708.GM23507@brightrain.aerifal.cx>
Date: Thu, 5 Feb 2015 15:37:08 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: faccessat and AT_SYMLINK_NOFOLLOW
On Wed, Feb 04, 2015 at 11:25:49AM -0800, Nick Kralevich wrote:
> 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...
It seems to me that what you're asking is whether AT_SYMLINK_NOFOLLOW
should mean "report accessibility for the symlink itself" or "force
failure when the target is a symlink"; the latter is what O_NOFOLLOW
does for open[at]. I don't have any strong opinion on the topic, but I
think the ambiguity is a strong suggestion that supporting
AT_SYMLINK_NOFOLLOW for faccessat is a bad idea. In particular, it
would be bad to choose an interpretation now and have POSIX later
mandate the opposite one.
Furthermore, faccessat (like access) is pretty much a useless
operation. It's fundamentally subject to TOCTOU races, and by default
it uses the read ids of the caller rather than the effective ids. The
intended use of these functions originally seems to have been letting
suid/sgid programs emulate the permissions of the user who invoked
them (rather than their current effective ids), but such usage is
incorrect and dangerous because of the race. I would go so far as to
say POSIX should mark both access and faccessat obsolescent. They have
no valid uses and plenty of erroneous uses that result in security
flaws. If you want to know if open will succeed, just try to do it.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
