From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6952 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: faccessat and AT_SYMLINK_NOFOLLOW Date: Thu, 5 Feb 2015 15:37:08 -0500 Message-ID: <20150205203708.GM23507@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1423168644 3088 80.91.229.3 (5 Feb 2015 20:37:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Feb 2015 20:37:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6965-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 05 21:37:24 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YJTAx-0005XQ-GQ for gllmg-musl@m.gmane.org; Thu, 05 Feb 2015 21:37:23 +0100 Original-Received: (qmail 29853 invoked by uid 550); 5 Feb 2015 20:37:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 29842 invoked from network); 5 Feb 2015 20:37:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6952 Archived-At: 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