Re: [gentoo-dev] An example overlayfs sandbox test

[Rich Freeman]

On Fri, Sep 22, 2017 at 6:29 PM, James McMechan
<james_mcmechan@×××××××.com> wrote:
> On Fri, Sep 22, 2017 at 5:18 PM, Rich Freeman <rich0@g.o> wrote:
>>On Fri, Sep 22, 2017 at 4:43 PM, James McMechan
>><james_mcmechan@×××××××.com> wrote:
>>>
>>> # now create a separate mount namespace non-persistent
>>> unshare -m bash
>>>
>>
>>If you're going to go to the trouble to set up a container, you might
>>as well add some more isolation:
>>
>>unshare --mount --net --pid --uts --cgroup --fork --ipc --mount-proc bash
>>
>
> I would not want to change the networking, it should already be working
> and I would be better served by not messing with it.
>

Well, that's the point.  You don't want networking to work during the
build phases.  Maybe you'd want it for the test phase.  In any case,
you would definitely want control over that in the ebuild.  Random
build systems shouldn't be talking to the internet, if for no other
reason than to avoid it fetching stuff to install that bypasses the
integrity checks.

If you create a new net namespace by default it won't have any
interfaces other than lo.

>
> The --mount-proc is not really helpful as I immediately remount the entire
> "/" filesystem at /mnt/gentoo and chroot into it after custom setup of proc sys and dev
>

As long as it doesn't see the host /proc then you're fine.  You just
wouldn't want to have it mounted into the container.

> Now I could see a use for  --map-root-user --user, then portage could run as
> root in the container with the least danger by being user portage:portage outside.
>

Certainly, but that takes a bit more work, and to be honest I've never
actually bothered to get it working using unshare.  It probably isn't
too difficult.

The options I listed basically "just work" without any real additional effort.

So, we're drifting in topic, but as long as we're coming up with
nice-to-have utilities it would be lovely if our install CDs had
something similar to systemd-nspawn to set up a container instead of a
chroot for performing the install.  If nothing else it would make
mount cleanup easier when you're done.  I imagine it would just be a
bit of shell scripting with util-linux on the CD - while nspawn is
bundled with systemd you don't need any of its fancier features for
doing an install.

Back on topic - none of this stuff will work on FreeBSD, which might
be an issue for those running Gentoo on that kernel.  Ditto for Prefix
I suppose.  I suspect that jails/etc would also do the job but you'd
need some arch-dependent code to set up the container.  Just about all
of these tricks are involving non-POSIX functionality.  Actually, I'm
not sure if even the current LD_PRELOAD approach is completely
portable, though it has the advantage of being entirely in userspace.

-- 
Rich