Re: [gentoo-dev] Reviving the Sandbox project

[James McMechan]

On Fri, Sep 22, 2017 at 5:27 AM, Rich Freeman <rich0@g.o> wrote: 
>On Fri, Sep 22, 2017 at 7:38 AM, Sergei Trofimovich <slyfox@g.o> 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