| 1 |
On Wed, 21 Jan 2015 10:38:20 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier |
| 5 |
> <aballier@g.o> wrote: |
| 6 |
> > On Wed, 21 Jan 2015 11:05:34 +0100 |
| 7 |
> > Michał Górny <mgorny@g.o> wrote: |
| 8 |
> > |
| 9 |
> >> Hello, developers. |
| 10 |
> >> |
| 11 |
> >> As you may recall, the main blocker for wide-establishment of |
| 12 |
> >> FEATURES=network-sandbox prohibiting network access within the |
| 13 |
> >> build environment is distcc. Since all connectivity is disabled, |
| 14 |
> >> distcc can no longer reach other distcc servers and build |
| 15 |
> >> efficiently. I therefore find it important to figure out a |
| 16 |
> >> solution. |
| 17 |
> >> |
| 18 |
> >> I see two generic approaches possible here: |
| 19 |
> >> |
| 20 |
> >> 1. proxying distcc from within the build environment, or |
| 21 |
> >> |
| 22 |
> >> 2. moving distcc-spawned processes back to parent's namespace. |
| 23 |
> > |
| 24 |
> > |
| 25 |
> > I haven't followed this at all, so this might be very stupid: |
| 26 |
> > Isn't it possible to whitelist distcc hosts ? |
| 27 |
> |
| 28 |
> That would only work with a proxy of some kind. |
| 29 |
> |
| 30 |
> A process running in a separate network namespace doesn't see any |
| 31 |
> network interfaces. It can't even get as far as iptables/etc for some |
| 32 |
> kind of filtering. Now, you could define an interface in the new |
| 33 |
> namespace, and then bridge that to the host network, and then apply |
| 34 |
> iptables rules to it. |
| 35 |
> |
| 36 |
|
| 37 |
Your last sentence mentions a nice possibility: |
| 38 |
1) Connect the sandbox network namespace to the global namespace (using |
| 39 |
a veth pair?) |
| 40 |
2) Enable forwarding (if I understand it right, it's even possible to |
| 41 |
do this for individual interfaces instead of globally, using |
| 42 |
/proc/sys/net/ipv{4,6}/conf/veth0 ) |
| 43 |
3) Set up suitable rules in the netfiler FORWARD chain to ensure only |
| 44 |
distcc gets through |
| 45 |
4) Set up SNAT or MASQUERADE in netfilter's nat table |
| 46 |
5) There you go! |
| 47 |
|
| 48 |
This is beautiful because is doesn't require any userland proxies, but |
| 49 |
of course, it would be difficult to set up in an automated fashion. So |
| 50 |
my proposal would be just to stay with the status quo, and document the |
| 51 |
above in the wiki for those who really want to use both network-sandbox |
| 52 |
and distcc despite the hassle. |
| 53 |
|
| 54 |
|
| 55 |
Regards, |
| 56 |
Luis Ressel |
Archives