Re: [PATCH] faccessat: fix error code on setreXid failure

[Rich Felker <dalias@libc.org>]

On Wed, Jan 31, 2018 at 01:20:45AM +0300, Alexander Monakov wrote:
> On Tue, 30 Jan 2018, Rich Felker wrote:
> > > We know we are not tracing this child, and stop notifications are only
> > > delivered if WUNTRACED is given in flags, aren't they?
> > 
> > I'm not sure what can happen if it's all running under strace -f or
> > something. And I'm not sure what the conditions for stop notifications
> > are. If it's assured that they can't happen then maybe the loop can be
> > removed.
> 
> Well, currently musl is just inconsistent, as in other instance(s?)
> (most notably in posix_spawn) it makes a single call to waitpid
> without retrying even though the same concerns apply.

OK, reading the spec I think without WUNTRACED or WCONTINUED, waitpid
can only succeed if the child has terminated. So it's probably fine
not to loop as long as signals are blocked.

It's perhaps (probably?) also safe to use CLONE_VM for the same reason
as in posix_spawn: because we have all (including implementation
internal) signals blocked, set*id() cannot succeed while the child
exists and thus you can't get into a situation where the child is
sharing memory but has different credentials. (The attack I have in
mind here to defend against is that the child drops root then runs
user-provided code, and the user-provided code modifies the code
that's running in the other process with elevated privileges.)

Rich