1 |
Dnia 2015-01-27, o godz. 03:03:31 |
2 |
Andrew Savchenko <bircoph@g.o> napisał(a): |
3 |
|
4 |
> On Sat, 24 Jan 2015 12:03:27 +0100 Michał Górny wrote: |
5 |
> > Dnia 2015-01-21, o godz. 11:05:34 |
6 |
> > Michał Górny <mgorny@g.o> napisał(a): |
7 |
> > |
8 |
> > > Parent namespace solution |
9 |
> > > ------------------------- |
10 |
> > > |
11 |
> > > The alternative is to wrap distcc so that parent network namespace is |
12 |
> > > regained. Sadly, for a start this requires SYS_CAP_ADMIN and access to |
13 |
> > > parent's /proc entry (so root privileges). |
14 |
> > > |
15 |
> > > We obviously don't want to lose userpriv, so we have to do with setuid |
16 |
> > > wrapper. Of course, setuid wrappers need to be written in C, so we need |
17 |
> > > to introduce C compiled executable in Portage. Then we need to take some |
18 |
> > > special care for it not to be abused, e.g. to access restricted network |
19 |
> > > namespaces of other processes. |
20 |
> > |
21 |
> > I've started to work on this, and I have all the setup.py code ready. |
22 |
> > Now it's just the C program and wrapping it all in Portage. |
23 |
> > |
24 |
> > The only remaining big issue is how to pass the correct namespace (or |
25 |
> > PID) to the distcc process, assuming it may be a deep child of |
26 |
> > the ebuild process. |
27 |
> > |
28 |
> > Possibilities: |
29 |
> > |
30 |
> > 1. Environment variables. Can't do because: |
31 |
> > |
32 |
> > a. one of the parent processes may scrub the environment, |
33 |
> > |
34 |
> > b. malicious process may override the variable, giving subprocess |
35 |
> > access to restricted system network namespace. |
36 |
> > |
37 |
> > 2. Files. Can't do because we would have to pass the path somehow (see |
38 |
> > 1.), and if we go for static path, we have collisions between multiple |
39 |
> > emerge processes. |
40 |
> |
41 |
> If we're not going to use PID isolation in future, PID-dependent |
42 |
> "static" file name may be used, where PID belongs to emerge. This |
43 |
> should solve the collision issue. |
44 |
|
45 |
I didn't want to make network-sandbox depend on another FEATUREs. |
46 |
|
47 |
> > 3. Parent process hierarchy. Seems fragile, requires a lot of scanning |
48 |
> > on every spawn and may end up in the wrong namespace if a subprocess |
49 |
> > calls setsid() and user put emerge in a separate namespace. |
50 |
> |
51 |
> Why not to use cgroups here? |
52 |
|
53 |
Not sure if cgroups help here. In our cgroup hierarchy, only child |
54 |
processes are governed. Not sure if setsid() behaves any different with |
55 |
that. |
56 |
|
57 |
> > 4. IPv4 socket. While it may seem a real dumb idea, it fits the case |
58 |
> > perfectly since it is only run if process is network-namespaced. We can |
59 |
> > surely reserve a static port early and run a daemon outputting |
60 |
> > the correct PID. Since the port is namespaced, every Portage process |
61 |
> > can have its own PID-daemon, and I don't know if there's any way of |
62 |
> > overriding the result from parent process. |
63 |
> |
64 |
> Looks fine, though the very idea to have extra daemons is |
65 |
> unpleasant. |
66 |
|
67 |
Yes, that's one of the issues. And spawning anything from inside ebuild |
68 |
process is terribly hacky and fragile since it doesn't do any proper |
69 |
process management. |
70 |
|
71 |
My initial implementation had even more issues: PATH changes were |
72 |
permanent because of env saving (so post-distcc phases still had distcc |
73 |
wrappers) and ld.so complained because setuid caused libsandbox not to |
74 |
be preloaded. Such errors could break configure checks. |
75 |
|
76 |
-- |
77 |
Best regards, |
78 |
Michał Górny |