Re: What is GLibc's policy on what is safe to use after a fork from a multithreaded program?

[Steven Stewart-Gallus <sstewartgallus00 at mylangara dot bc dot ca>]

> Do you eventually call exec?
> 
> If yes, it's could be worthwhile to extend posix_spawn, assuming 
> that 
> agreement can be reached about a useful set of new actions.
> 
> -- 
> Florian Weimer / Red Hat Product Security

I think that it'd be great to extend posix_spawn with some sandboxing
features.

posix_spawnattr_setunshare_np(CLONE_NEWIPC | etc...) seems reasonable
to me.

posix_spawnattr_setroot_np("/myrootdir") would be useful as setting up
a proper chroot is fraught with security problems and having an
existing library function would help avoid dumb mistakes.  An
advantage of taking an already constructed root directory as a path
it'd avoid problems with taking a complicated and ultimately
insufficient custom format for constructing the root directory.  I'd
prefer if it used pivot_root over chroot because then the old
directory can be unmounted but there's not a way to do that without
unsharing the mount namespace.

posix_spawnattr_setresuid_np, and_spawnattr_setresgid_np are useful
for similar reasons as posix_spawnattr_setroot_np would be.

If posix_spawnattr_setresuid_np and posix_spawnattr_setresgid_np are
added posix_spawnattr_setgroups_np and posix_spawnattr_setcaps_np
might be reasonable as well.

In my own spawn I don't have this feature (I have it at start.c at
https://gitorious.org/linted/linted/source/56b96eab69a9fa37707bf92fe897c91a96ddc589:src/start/start.c
instead) but a posix_spawnattr_setcloseall_np could be very useful.
This is extremely complicated and annoying to get right so
centralizing it would be useful.

It's worth noting though that for my own personal use posix_spawn is
insufficient so adding sandboxing features posix_spawn can only stand
on its merits to others.

First, I'm making a sort of init system to manage my processes and I
am using (and I think others might want to use as well) the clunky
convention of systemd where the main start process that is being
passed file descriptors is labelled with an environment variable
called LISTEN_PID.

Second, I enjoy being able to put in tighter error handling for
failures during a spawn.  For example, execve can fail by having the
process killed by an out of memory error and I'm considering adding in
a horrible hack I figured out to stop a process right after execve so
I can wait on it and check if it is stopped or killed.

If sandboxing features are added to posix_spawn there are a number of
complicated problems one has to solve so I would encourage one to look
at existing work such as my own spawn at
https://gitorious.org/linted/linted/source/56b96eab69a9fa37707bf92fe897c91a96ddc589:src/spawn/spawn.c
to avoid running into known problems.

Thank you,
Steven Stewart-Gallus