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. 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. 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. Any other ideas? -- Best regards, Michał Górny
pgpg1IjNH_Pcv.pgp
Description: OpenPGP digital signature
