On Fri, 22 Sep 2017 15:06:49 +0000 James McMechan <james_mcmec...@hotmail.com> wrote:
> On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman <ri...@gentoo.org> > wrote: > >On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich > ><sly...@gentoo.org> wrote: > >> > >> Some other distros try harder to isolate build environment either > >> through chroot and/or private mount/user/network namespace that > >> contains only explicitly specified files in build environment. > >> > >> That would require more cooperation from package manager to fetch > >> list of all visible depends. > >> > > > >I definitely think this is something that would be VERY useful to > >have, because it makes build-time dependency issues almost > >impossible. > > > >However, you don't need that complete solution just to have a > >sandbox. You could simply create a container with the entire > >contents of the main filesystem, but read-only, with the exception > >of the build area. That would replicate the functionality of the > >current sandbox and would be easier than building out just the files > >specified in the dependencies. > > > >The main issue I see with making it dependency aware is performance. > >You would need to walk all the dependencies and their run-time > >dependencies, and the system set, and then individually bind-mount > >the files that belong to them read-only into the container. That > >isn't necessarily difficult, but I imagine that it would be slow. > >Walking the dependencies obviously already happens during resolution > >so that could probably be cached. You could also cache the list of > >files for the system set, and you could even maintain a snapshot of > >these that is used as the base of the container (somebody would need > >to work out the savings of doing this vs the cost of updating it > >every time a system set package changes). > > > >However, the main thing I wanted to point out is that you don't need > >a dependency-aware solution to just replace the existing sandbox. > > > >> I like clear sandbox error reporting. > > > >As far as error reporting goes, you would get kernel-level errors > >like attempting to write to a read-only bind mount, or trying to > >read a file that doesn't exist. To a portage dev it should be > >pretty obvious what is going on. You could add canned text to the > >portage error output at the end. I'm not sure how visible the > >problems would be to portage except to the degree that the build > >system makes them visible > >- it would just see make terminate with a non-zero return. > > > >I would think that containers would be almost completely bug-free > >though. The only thing I could see as an issue is some build system > >that relies on IPC with the host, network access, etc. Namespaces > >themselves are very robust, and the kernel already looks at every > >process as belonging to a set of namespaces even in the default case > >where you only have one set of namespaces on the system, so they > >don't involve different code paths/etc. > > > >-- > >Rich > > Another possibility, could be to have the sandbox be an overlayfs > not of the build directory but of the entire system starting at "/" > and stick that into the container, only CLONE_NEWNS looks to be > needed. > > A container with all writes going to the upper layer of the overlay > could be safe against even #RM -RF / and other disasters, while still > tracking what is happening during the build. > > Should performance be too much of a problem having a bind mount of > the build directory on top of the overlay should give normal > performance to everything that is obeying good practice. > > After the build completes the directory that was mounted as upper > could be scanned to find any wayward writes that had occurred... > > This would not require LD_PRELOAD or ptrace eliminating most of the > "high magic" currently used. > > Just yesterday I had a lot of ptrace failures while trying something > odd with ROOT= and custom USE > > Jim McMechan I kinda like this idea, It looks to me to have pretty much all the benefits of a sandbox and nearly none of the drawbacks. Sounds like it should get more research into this idea, figure out it's limitations and if there are any caveats. -- Brian Dolbec <dolsen>
