Date: Wed, 31 Jan 2018 22:19:37 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] faccessat: fix error code on setreXid failure 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
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.