Re: [gentoo-user] Can I use containers?

[Rich Freeman]

On Sat, May 18, 2019 at 12:44 PM Grant Taylor
<gtaylor@×××××××××××××××××××××.net> wrote:
>
> On 5/18/19 9:26 AM, Peter Humphrey wrote:
> > Hello list,
>
> Hi,
>
> > Can anyone answer this?
>
> I would think that containers could be made to do this.  But I'm not a
> fan of the containerization systems that I've seen.  They seem to be too
> large and try to control too many things and impose too many
> limitations.

I'd be interested if there are other scripts people have put out
there, but I agree that most of the container solutions on Linux are
overly-complex.

I personally use nspawn, which is actually pretty minimal, but it
depends on systemd, which I'm sure many would argue is overly complex.
:)  However, if you are running systemd you can basically do a
one-liner that requires zero setup to turn a chroot into a container.

On to the original questions about mounts:

In general you can mount stuff in containers without issue.  There are
two ways to go about it.  One is to mount something on the host and
bind-mount it into the container, typically at launch time.  The other
is to give the container the necessary capabilities so that it can do
its own mounting (typically containers are not given the necessary
capabilities, so mounting will fail even as root inside the
container).

I believe the reason the wiki says to be careful with mounts has more
to do with UID/GID mapping.  As you are using nfs this is already an
issue you're probably dealing with.  You're probably aware that
running nfs with multiple hosts with unsynchronized passwd/group files
can be tricky, because linux (and unix in general) works with
UIDs/GIDs, and not really directly with names, so if you're doing
something with one UID on one host and with a different UID on another
host you might get unexpected permissions behavior.

In a nutshell the same thing can happen with containers, or for that
matter with chroots.  If you have identical passwd/group files it
should be a non-issue.  However, if you want to do mapping with
unprivileged containers you have to be careful with mounts as they
might not get translated properly.  Using completely different UIDs in
a container is their suggested solution, which is fine as long as the
actual container filesystem isn't shared with anything else.  That
tends to be the case anyway when you're using container
implementations that do a lot of fancy image management.  If you're
doing something very minimal and just using a path/chroot on the host
as your container then you need to be mindful of your UIDs/GIDs if you
go accessing anything from the host directly.

The other thing I'd be careful with is mounting physical devices in
more than one place.  Since you're actually sharing a kernel I suspect
linux will "do the right thing" if you mount an ext4 on /dev/sda2 on
two different containers, but I've never tried it (and again doing
that requires giving containers access to even see sda2 because they
probably won't see physical devices by default).  In a VM environment
you definitely can't do this, because the VMs are completely isolated
at the kernel level and having two different kernels having dirty
buffers on the same physical device is going to kill any filesystem
that isn't designed to be clustered.  In a container environment the
two containers aren't really isolated at the actual physical
filesystem level since they share the kernel, so I think you'd be fine
but I'd really want to test or do some research before relying on it.

In any case, the more typical solution is to just mount everything on
the host and then bind-mount it into the container.  So, you could
mount the nfs in /mnt and then bind-mount that into your container.
There is really no performance hit and it should work fine without
giving the container a bunch of capabilities.

-- 
Rich