Re: [PATCH v4 0/3] Linux: Fix posix_spawn when user with time namespaces

[Andrei Vagin <avagin@gmail.com>]

On Mon, May 30, 2022 at 02:58:01PM +0200, Florian Weimer wrote:
> * Andrei Vagin:
> 
> [CLONE_NEWTIME and vfork]
> 
> >> Breaking vfork is really a bit of a hassle for us, and the workaround
> >> code is quite non-trivial and will have to implemented across many
> >> projects (not just glibc).  An unshare request that takes effect on
> >> execve only would really help.
> >
> > Is the problem that vfork fails if a process has half-entered a time
> > namespace?
> 
> Exactly.  Anything that implements a general-purpose process launching
> facility on top of vfork now needs to implement fork fallback (after
> vfork failure), so that launching processes still works if the original
> process has called unshare(CLONE_NEWTIME).  
> 
> In glibc, this affects posix_spawn, but other libcs are also impacted,
> and so is any custom posix_spawn-like interface that uses vfork
> internally.  Without fork fallback, they turn unusable if anything in
> the process has previously called unshare(CLONE_NEWTIME).  The fallback
> implementation tends to be complicated if it's necessary to report
> execve and other errors to the caller.  There is a choice between the
> O_CLOEXEC pipe hack (which has become more complex to implement due to
> close_range support), or a shared mapping has to be created using
> MAP_SHARED, and the subprocess writes error information to that (which
> adds more potentially costly MM updates).  MAP_SHARED is probably easier
> to implement than the pipe approach (no interference possible from file
> actions), but for glibc, Adhemerval wrote something based on the pipe
> approach.
> 
> But the key point is that any general-purpose wrapper around vfork now
> has to implement fork fallback.
> 
> Regarding the patch you sketched, we'd probably have to introduce a new
> flag (not CLONE_NEWTIME) for this because the difference in behavior is
> quite visible.

I agree that if we want to switch timens on exec, we need to introduce a
new clone flag. But I would like to avoid doing that. I think we can
live with the current clone flag if we allow switching timens only when
exec is executed by a vfork-ed process. In this case, the chance to
affect existing users is very low, isn't it?


Without the new change, vfork fails if the currect process has unshared
timens. With the change, vfork creates a new process, and the following
exec executes a binary in the target timens.

Thanks,
Andrei