[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Sep 2014 18:46:14 +0200
From: u-wsnj@...ey.se
To: musl@...ts.openwall.com
Subject: Re: faccessat and AT_SYM_NOFOLLOW
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).
Regards,
Rune
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.
