1 |
Hello, developers. |
2 |
|
3 |
As you may recall, the main blocker for wide-establishment of |
4 |
FEATURES=network-sandbox prohibiting network access within the build |
5 |
environment is distcc. Since all connectivity is disabled, distcc can |
6 |
no longer reach other distcc servers and build efficiently. I therefore |
7 |
find it important to figure out a solution. |
8 |
|
9 |
I see two generic approaches possible here: |
10 |
|
11 |
1. proxying distcc from within the build environment, or |
12 |
|
13 |
2. moving distcc-spawned processes back to parent's namespace. |
14 |
|
15 |
|
16 |
distcc client/server solution |
17 |
----------------------------- |
18 |
|
19 |
The most obvious solution to me is to employ a client/server model |
20 |
where a system-wide daemon is running, parsing /etc/distcc/hosts |
21 |
and doing all the network activity. Clients can only connect to it via |
22 |
a UNIX socket. While at it, we also make it responsible for task |
23 |
scheduling so that parallel builds don't go over the task limits, |
24 |
and maybe even integrate into distccd so that it is both aware of local |
25 |
and remote builds. |
26 |
|
27 |
Of course, that's a pipe dream assuming there will be somewhere to do |
28 |
all the work, upstream will accept it and users will accept some |
29 |
limitations (like no easy per-process overrides of DISTCC_HOSTS). So |
30 |
better to look into something more realistic. |
31 |
|
32 |
|
33 |
Generic proxy solution |
34 |
---------------------- |
35 |
|
36 |
The simplest solution so far seems to be setting a generic SOCKS proxy |
37 |
inside the build environment, and wrapping distcc so that it will use |
38 |
it for network access. |
39 |
|
40 |
Unless we do some extra magic which don't want to do, this means that |
41 |
other apps can also abuse the proxy to reach outside sandbox. However, |
42 |
network-sandbox is not really a security feature, so I don't think that |
43 |
is important. At least as long as we don't export it globally :). |
44 |
|
45 |
Of course, software is a problem. We'd need at least some SOCKS server |
46 |
for Portage (at least a very simple one), and as far as I'm aware |
47 |
distcc does not support SOCKS directly, so tsocks in addition to that. |
48 |
|
49 |
|
50 |
Parent namespace solution |
51 |
------------------------- |
52 |
|
53 |
The alternative is to wrap distcc so that parent network namespace is |
54 |
regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to |
55 |
parent's /proc entry (so root privileges). |
56 |
|
57 |
We obviously don't want to lose userpriv, so we have to do with setuid |
58 |
wrapper. Of course, setuid wrappers need to be written in C, so we need |
59 |
to introduce C compiled executable in Portage. Then we need to take some |
60 |
special care for it not to be abused, e.g. to access restricted network |
61 |
namespaces of other processes. |
62 |
|
63 |
|
64 |
Any other ideas? |
65 |
|
66 |
-- |
67 |
Best regards, |
68 |
Michał Górny |