From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6950 Path: news.gmane.org!not-for-mail From: Nick Kralevich Newsgroups: gmane.linux.lib.musl.general Subject: faccessat and AT_SYMLINK_NOFOLLOW Date: Wed, 4 Feb 2015 11:25:49 -0800 Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1423077968 12226 80.91.229.3 (4 Feb 2015 19:26:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Feb 2015 19:26:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6963-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 04 20:26:07 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 1YJ5aN-0003RT-OM for gllmg-musl@m.gmane.org; Wed, 04 Feb 2015 20:26:03 +0100 Original-Received: (qmail 26333 invoked by uid 550); 4 Feb 2015 19:26:02 -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 26322 invoked from network); 4 Feb 2015 19:26:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OGozxirEIft47Bv8FA/fKd/WfDsdsxJ9IMgitCM9fyU=; b=h2aTN1p9xcwvDe4g0Mui7tsuCdmX7q8hKNj26pv29M2+WTG/qwwy6DnlMvigs0oUli edB1LPGCuqtZZjYkAaBrzzOohq4aqLP4oGgdYL744yfePXXf4xWpGSih8N6r9LwMATFj cE0nNS1III961vJv1NRehYY3Rm8R4ytC8XqC5zn7g/dqoI2RQuLhBxl8DwBzpWUrCRhS +3KqwnINtYbzUH+ae2VshhkjM0XUNYuZnPotLZvD5YOw/XGnvgSSPQdN3UrthjFxfFAv VOCP/PsmVzFkvjIl+mpUOSxl7HIHv9uMWsFnV3wph/PXsdsylNuAmReANeRHW1CUeQY2 pi6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OGozxirEIft47Bv8FA/fKd/WfDsdsxJ9IMgitCM9fyU=; b=g1CxTD5ORTAN35KXtx9yN7GtMre4tUy7MUUhbs6cKCglDwBTsJ634IGekybmR8izSo 9cZ00X/ENQvEWnKyVqdV+LmkEyitv0X4tl1KcttA01e3xbDw732pWxKX+81axfd0YeiG z6QGI1DP+ByDbmxTrDYQ2oOF1rSqOCOiuse1oZT71PI3bwvzL87Ge/TyWUSUlSB6l+IG EeJ2KBcdlGhx+uFifsQI5KketK5Bc5NHOIqEzhgtzS7DNomUiIoE2Jg3nB14NU591dZ+ bt6ux2Rkxah6lRaGI4bF9tbOjW+mlPwd87gTnujdVo466IHx8Y83gG5H7b2DcFdMdNar +95w== X-Gm-Message-State: ALoCoQkaDOS5Oj+S7g5rF8CIPk3M9vkHCRwaE6yYn26tju0vyD1eOoV+ZJLMgi/awLwor74dxhky X-Received: by 10.202.133.131 with SMTP id h125mr15993713oid.23.1423077949708; Wed, 04 Feb 2015 11:25:49 -0800 (PST) Xref: news.gmane.org gmane.linux.lib.musl.general:6950 Archived-At: 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