From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6198 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: faccessat and AT_SYM_NOFOLLOW Date: Thu, 25 Sep 2014 17:15:04 -0400 Message-ID: <20140925211504.GO23797@brightrain.aerifal.cx> References: <20140925160110.GA25937@brightrain.aerifal.cx> <20140925164614.GO20593@example.net> 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 1411679728 28411 80.91.229.3 (25 Sep 2014 21:15:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Sep 2014 21:15:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6211-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 25 23:15:19 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XXGNh-0002Kq-4D for gllmg-musl@plane.gmane.org; Thu, 25 Sep 2014 23:15:17 +0200 Original-Received: (qmail 20223 invoked by uid 550); 25 Sep 2014 21:15:16 -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 20211 invoked from network); 25 Sep 2014 21:15:16 -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:6198 Archived-At: On Thu, Sep 25, 2014 at 10:03:06PM +0100, Justin Cormack wrote: > On Thu, Sep 25, 2014 at 5:46 PM, wrote: > > On Thu, Sep 25, 2014 at 12:01:10PM -0400, Rich Felker wrote: > >> to get the file ownership and mode and performs its own access > >> permissions check in userspace. This is imprecise and does not > >> respect ACLs or any other advanced permission models provided by > > > > Of course, that's plainly wrong. > > > >> So my conclusion? There are some moderate-level documentation errors. > >> glibc implements the flag, but not correctly. The changes I would > >> recommend to the documentation: > >> > >> 1. Document that AT_SYM_NOFOLLOW is not standard for this function, > >> and is a glibc extension. (uclibc is just a copy of glibc code) > >> > >> 2. Document that AT_SYM_NOFOLLOW and AT_EACCESS are emulated and > >> unreliable on glibc. > >> > >> 3. Document that the man page is covering the POSIX/glibc function > >> details, and the kernel syscall does not support flags at all. > >> (This might aid in getting the kernel folks to add a new faccessat4 > >> syscall that would do flags at the kernel level.) > >> > >> Do these sound reasonable? > > > > Yes (but I would look for a stronger wording than "unreliable" :) > > > >> Issue 2: Should musl support or ignore the AT_SYM_NOFOLLOW with > >> faccessat? > > > > [your analysis looks for my eyes correct] > > > > I would not bother implementing something which does not make sense > > (worse, would mislead the programmers, iow inflicting damage instead > > of doing any good). > > Seems reasonable. > > I note that Musl calls faccessat with the flag though, even though the > syscall appears to not be defined with the flag, so that should > probably be fixed, if I havent misread anything. You mean in making the syscall? Yes, that still seems to be leftover from before I was aware that the syscall did not take any flags. It could be removed to save a few bytes. > I don't think anyone will add faccessat4, given that the whole idea is > basically broken. AT_EACCESS, which is standard, should be supported correctly. musl does so, but at some rather extreme cost (forking). glibc just gives a nonsensical result. So it would be nice if the kernel could handle it correctly, even though this is largely a useless interface. Rich