| 1 |
On Wed, Jan 21, 2015 at 10:00 AM, Alexis Ballier <aballier@g.o> wrote: |
| 2 |
> On Wed, 21 Jan 2015 11:05:34 +0100 |
| 3 |
> Michał Górny <mgorny@g.o> wrote: |
| 4 |
> |
| 5 |
>> Hello, developers. |
| 6 |
>> |
| 7 |
>> As you may recall, the main blocker for wide-establishment of |
| 8 |
>> FEATURES=network-sandbox prohibiting network access within the build |
| 9 |
>> environment is distcc. Since all connectivity is disabled, distcc can |
| 10 |
>> no longer reach other distcc servers and build efficiently. I |
| 11 |
>> therefore find it important to figure out a solution. |
| 12 |
>> |
| 13 |
>> I see two generic approaches possible here: |
| 14 |
>> |
| 15 |
>> 1. proxying distcc from within the build environment, or |
| 16 |
>> |
| 17 |
>> 2. moving distcc-spawned processes back to parent's namespace. |
| 18 |
> |
| 19 |
> |
| 20 |
> I haven't followed this at all, so this might be very stupid: |
| 21 |
> Isn't it possible to whitelist distcc hosts ? |
| 22 |
|
| 23 |
That would only work with a proxy of some kind. |
| 24 |
|
| 25 |
A process running in a separate network namespace doesn't see any |
| 26 |
network interfaces. It can't even get as far as iptables/etc for some |
| 27 |
kind of filtering. Now, you could define an interface in the new |
| 28 |
namespace, and then bridge that to the host network, and then apply |
| 29 |
iptables rules to it. |
| 30 |
|
| 31 |
I will second Michael's comment that distcc support shouldn't really |
| 32 |
be required for making this feature a mainstream one. I'm all for |
| 33 |
getting distcc working with this, but there is no reason the 98% of |
| 34 |
Gentoo users who don't use distcc can't benefit from network isolation |
| 35 |
while we wait to get it working for everybody else. |
| 36 |
|
| 37 |
-- |
| 38 |
Rich |
Archives