Re: [gentoo-dev] Functional portage with namespace (Was: Integrating Portage with other package managers)

[Rich Freeman]

On Thu, Mar 8, 2018 at 7:46 PM, Benda Xu <heroxbd@g.o> wrote:
> Rich Freeman <rich0@g.o> writes:
>
>> If you have util-linux installed then try running (as any user - you
>> don't have to be root): unshare -i -m -n -p -u -C -f --mount-proc -U
>> -r /bin/bash
>>
>> Congrats.  You are now root in a container.  You're in the same root
>> filesystem as always.  You'll note that you can't actually see
>> anything that you couldn't see before.  If you run ps -ea you'll see
>> that you're the only process running on the system.  Devices like
>> /dev/sda aren't actually accessible.  A lot of container managers
>> would mount a new /dev and just hide most of that stuff.  You can
>> probably imagine how something like this could be useful for isolating
>> processes.
>
> Just a side node, this seems to be the ultimate sandbox we (Gentoo and
> portage) are after.  With this, we might even be able to have portage
> full functional: a build is completely determined and only determined by
> the dependencies and USE flags.
>

I'm not sure how well this would perform, but I had given this a bit
of thought a few years ago.  There are two obvious ways to go about
this: the sandbox or containers.

Either way you first go through the declared dependencies (and @system
under our current policies) and obtain a list of all files installed
by these packages.  Then you either bind mount those files into a
container, or add them to the sandbox configuration as readable.
Right now the sandbox rules are set to allow read access by default on
everything, but this is just a one-liner to change, which would cause
the sandbox to generate an error if a file is read which isn't
explicitly enabled.

The container solution is going to be cleaner because it also helps
curb errors from automagic build systems.  These build systems
wouldn't even be able to detect files not owned by a declared
dependency.  With the sandbox approach those files would be visible,
but would generate errors when accessed (so at least we get a bug
report, but users still have to deal with the issue).  Sure, this
would to some extent hide problems, but then again the automagic build
system would be defeated all the same.

The real question is how long it takes to extract those file lists and
create all those bind mounts.  In the case of @system some of this
could be cached.  I'm pretty sure the file lists would be quite fast -
we only need to go one level deep on the dependency tree (I think).  I
suspect the bind mounts would be fast, but I haven't tried to
benchmark it.  I also have no idea how sandbox performs with a very
long list of rules.

-- 
Rich