Dnia 2015-01-27, o godz. 03:03:31 Andrew Savchenko <birc...@gentoo.org> napisał(a):
> 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. I didn't want to make network-sandbox depend on another FEATUREs. > > 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? Not sure if cgroups help here. In our cgroup hierarchy, only child processes are governed. Not sure if setsid() behaves any different with that. > > 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. Yes, that's one of the issues. And spawning anything from inside ebuild process is terribly hacky and fragile since it doesn't do any proper process management. My initial implementation had even more issues: PATH changes were permanent because of env saving (so post-distcc phases still had distcc wrappers) and ld.so complained because setuid caused libsandbox not to be preloaded. Such errors could break configure checks. -- Best regards, Michał Górny
pgpxKYzNyUNS1.pgp
Description: OpenPGP digital signature
