[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140925211504.GO23797@brightrain.aerifal.cx>
Date: Thu, 25 Sep 2014 17:15:04 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: faccessat and AT_SYM_NOFOLLOW
On Thu, Sep 25, 2014 at 10:03:06PM +0100, Justin Cormack wrote:
> On Thu, Sep 25, 2014 at 5:46 PM, <u-wsnj@...ey.se> 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
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.
