From: u-wsnj@aetey.se
To: musl@lists.openwall.com
Subject: Re: faccessat and AT_SYM_NOFOLLOW
Date: Thu, 25 Sep 2014 18:46:14 +0200 [thread overview]
Message-ID: <20140925164614.GO20593@example.net> (raw)
In-Reply-To: <20140925160110.GA25937@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2014-09-25 16:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-25 16:01 Rich Felker
2014-09-25 16:46 ` u-wsnj [this message]
2014-09-25 21:03 ` Justin Cormack
2014-09-25 21:15 ` Rich Felker
[not found] ` <20140925160110.GA25937-C3MtFaGISjmo6RMmaWD+6Sb1p8zYI1N1@public.gmane.org>
2014-09-28 17:05 ` Rob Landley
2014-09-28 21:20 ` Rich Felker
2014-09-29 16:27 ` Alexander Monakov
2014-09-29 16:40 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140925164614.GO20593@example.net \
--to=u-wsnj@aetey.se \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).