Re: [gentoo-dev] Reviving the Sandbox project

[Rich Freeman]

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