1 |
On Fri, 22 Sep 2017 15:06:49 +0000 |
2 |
James McMechan <james_mcmechan@×××××××.com> wrote: |
3 |
|
4 |
> On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman <rich0@g.o> |
5 |
> wrote: |
6 |
> >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich |
7 |
> ><slyfox@g.o> wrote: |
8 |
> >> |
9 |
> >> Some other distros try harder to isolate build environment either |
10 |
> >> through chroot and/or private mount/user/network namespace that |
11 |
> >> contains only explicitly specified files in build environment. |
12 |
> >> |
13 |
> >> That would require more cooperation from package manager to fetch |
14 |
> >> list of all visible depends. |
15 |
> >> |
16 |
> > |
17 |
> >I definitely think this is something that would be VERY useful to |
18 |
> >have, because it makes build-time dependency issues almost |
19 |
> >impossible. |
20 |
> > |
21 |
> >However, you don't need that complete solution just to have a |
22 |
> >sandbox. You could simply create a container with the entire |
23 |
> >contents of the main filesystem, but read-only, with the exception |
24 |
> >of the build area. That would replicate the functionality of the |
25 |
> >current sandbox and would be easier than building out just the files |
26 |
> >specified in the dependencies. |
27 |
> > |
28 |
> >The main issue I see with making it dependency aware is performance. |
29 |
> >You would need to walk all the dependencies and their run-time |
30 |
> >dependencies, and the system set, and then individually bind-mount |
31 |
> >the files that belong to them read-only into the container. That |
32 |
> >isn't necessarily difficult, but I imagine that it would be slow. |
33 |
> >Walking the dependencies obviously already happens during resolution |
34 |
> >so that could probably be cached. You could also cache the list of |
35 |
> >files for the system set, and you could even maintain a snapshot of |
36 |
> >these that is used as the base of the container (somebody would need |
37 |
> >to work out the savings of doing this vs the cost of updating it |
38 |
> >every time a system set package changes). |
39 |
> > |
40 |
> >However, the main thing I wanted to point out is that you don't need |
41 |
> >a dependency-aware solution to just replace the existing sandbox. |
42 |
> > |
43 |
> >> I like clear sandbox error reporting. |
44 |
> > |
45 |
> >As far as error reporting goes, you would get kernel-level errors |
46 |
> >like attempting to write to a read-only bind mount, or trying to |
47 |
> >read a file that doesn't exist. To a portage dev it should be |
48 |
> >pretty obvious what is going on. You could add canned text to the |
49 |
> >portage error output at the end. I'm not sure how visible the |
50 |
> >problems would be to portage except to the degree that the build |
51 |
> >system makes them visible |
52 |
> >- it would just see make terminate with a non-zero return. |
53 |
> > |
54 |
> >I would think that containers would be almost completely bug-free |
55 |
> >though. The only thing I could see as an issue is some build system |
56 |
> >that relies on IPC with the host, network access, etc. Namespaces |
57 |
> >themselves are very robust, and the kernel already looks at every |
58 |
> >process as belonging to a set of namespaces even in the default case |
59 |
> >where you only have one set of namespaces on the system, so they |
60 |
> >don't involve different code paths/etc. |
61 |
> > |
62 |
> >-- |
63 |
> >Rich |
64 |
> |
65 |
> Another possibility, could be to have the sandbox be an overlayfs |
66 |
> not of the build directory but of the entire system starting at "/" |
67 |
> and stick that into the container, only CLONE_NEWNS looks to be |
68 |
> needed. |
69 |
> |
70 |
> A container with all writes going to the upper layer of the overlay |
71 |
> could be safe against even #RM -RF / and other disasters, while still |
72 |
> tracking what is happening during the build. |
73 |
> |
74 |
> Should performance be too much of a problem having a bind mount of |
75 |
> the build directory on top of the overlay should give normal |
76 |
> performance to everything that is obeying good practice. |
77 |
> |
78 |
> After the build completes the directory that was mounted as upper |
79 |
> could be scanned to find any wayward writes that had occurred... |
80 |
> |
81 |
> This would not require LD_PRELOAD or ptrace eliminating most of the |
82 |
> "high magic" currently used. |
83 |
> |
84 |
> Just yesterday I had a lot of ptrace failures while trying something |
85 |
> odd with ROOT= and custom USE |
86 |
> |
87 |
> Jim McMechan |
88 |
|
89 |
I kinda like this idea, It looks to me to have pretty much all the |
90 |
benefits of a sandbox and nearly none of the drawbacks. |
91 |
|
92 |
Sounds like it should get more research into this idea, figure out it's |
93 |
limitations and if there are any caveats. |
94 |
|
95 |
-- |
96 |
Brian Dolbec <dolsen> |