Re: faccessat and AT_SYM_NOFOLLOW

[Justin Cormack <justin@specialbusservice.com>]

On Thu, Sep 25, 2014 at 5:46 PM,  <u-wsnj@aetey.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.

I don't think anyone will add faccessat4, given that the whole idea is
basically broken.

Justin