Hi, Ryan Hill wrote: > Probably best to make FEATURES=distcc disable network-sandbox > then. People enabling it are explicitly saying they want to access > the network.
Do you really think it is a good behavior to automatically disable something you can call a "security feature"? At least there should be a warning, not? Think about situations where the user just know "network-sandbox is important, because it will protect my system from unwanted modifications" (the thing where the test suite for example will write to the local, productive, database server...) and therefore explicitly enable that feature by hand. But the user is *also* using distcc to speed up the compilation/update time in his/her network. The user maybe knows that distcc is using network, but he/she might be surprised that it won't work together with the network-sandbox feature. If we now silently disable network-sandbox because the user also set distcc he/she might be even more surprised when he/she noticed that his/her local productive database system was accessed by emerge though he/she enabled network-sandbox feature to prevent this (but which was automatically disabled without a warning). Because it is security relevant and the impact could be a real problem I won't even show just a warning the user could miss. If network-sandbox *and* distcc are both set, emerge should fail complaining about the problem. This is something the user should be aware of and must be solved by hand. So if we decide to enable the network-sandbox feature by default (which we should do), users also using distcc must take action. And if in future we will solve the problem so that both features can be used together, we should send out a news item for people using the distcc feature telling them "Now you can re-enable (the default) network-sandbox feature"... -Thomas
