On Sat, 24 Jan 2015 12:03:27 +0100 Michał Górny wrote: > Dnia 2015-01-21, o godz. 11:05:34 > Michał Górny <mgo...@gentoo.org> napisał(a): > > > Parent namespace solution > > ------------------------- > > > > The alternative is to wrap distcc so that parent network namespace is > > regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to > > parent's /proc entry (so root privileges). > > > > We obviously don't want to lose userpriv, so we have to do with setuid > > wrapper. Of course, setuid wrappers need to be written in C, so we need > > to introduce C compiled executable in Portage. Then we need to take some > > special care for it not to be abused, e.g. to access restricted network > > namespaces of other processes. > > I've started to work on this, and I have all the setup.py code ready. > Now it's just the C program and wrapping it all in Portage. > > The only remaining big issue is how to pass the correct namespace (or > PID) to the distcc process, assuming it may be a deep child of > the ebuild process. > > Possibilities: > > 1. Environment variables. Can't do because: > > a. one of the parent processes may scrub the environment, > > b. malicious process may override the variable, giving subprocess > access to restricted system network namespace. > > 2. Files. Can't do because we would have to pass the path somehow (see > 1.), and if we go for static path, we have collisions between multiple > emerge processes.
If we're not going to use PID isolation in future, PID-dependent "static" file name may be used, where PID belongs to emerge. This should solve the collision issue. > 3. Parent process hierarchy. Seems fragile, requires a lot of scanning > on every spawn and may end up in the wrong namespace if a subprocess > calls setsid() and user put emerge in a separate namespace. Why not to use cgroups here? > 4. IPv4 socket. While it may seem a real dumb idea, it fits the case > perfectly since it is only run if process is network-namespaced. We can > surely reserve a static port early and run a daemon outputting > the correct PID. Since the port is namespaced, every Portage process > can have its own PID-daemon, and I don't know if there's any way of > overriding the result from parent process. Looks fine, though the very idea to have extra daemons is unpleasant. Best regards, Andrew Savchenko
pgpx4R3Fllh21.pgp
Description: PGP signature
