Hello, developers. As you may recall, the main blocker for wide-establishment of FEATURES=network-sandbox prohibiting network access within the build environment is distcc. Since all connectivity is disabled, distcc can no longer reach other distcc servers and build efficiently. I therefore find it important to figure out a solution.
I see two generic approaches possible here: 1. proxying distcc from within the build environment, or 2. moving distcc-spawned processes back to parent's namespace. distcc client/server solution ----------------------------- The most obvious solution to me is to employ a client/server model where a system-wide daemon is running, parsing /etc/distcc/hosts and doing all the network activity. Clients can only connect to it via a UNIX socket. While at it, we also make it responsible for task scheduling so that parallel builds don't go over the task limits, and maybe even integrate into distccd so that it is both aware of local and remote builds. Of course, that's a pipe dream assuming there will be somewhere to do all the work, upstream will accept it and users will accept some limitations (like no easy per-process overrides of DISTCC_HOSTS). So better to look into something more realistic. Generic proxy solution ---------------------- The simplest solution so far seems to be setting a generic SOCKS proxy inside the build environment, and wrapping distcc so that it will use it for network access. Unless we do some extra magic which don't want to do, this means that other apps can also abuse the proxy to reach outside sandbox. However, network-sandbox is not really a security feature, so I don't think that is important. At least as long as we don't export it globally :). Of course, software is a problem. We'd need at least some SOCKS server for Portage (at least a very simple one), and as far as I'm aware distcc does not support SOCKS directly, so tsocks in addition to that. 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. Any other ideas? -- Best regards, Michał Górny
pgpqn42Mh1Tax.pgp
Description: OpenPGP digital signature
