[lxc-users] Unprivileged container squashfs file system

Wed Jul 6 19:28:38 UTC 2016

Thanks for the quick response.  I am particularly interested in the shiftfs
and may try to patch that in.  A single followup question below.

On Wed, Jul 6, 2016 at 2:03 PM, Serge E. Hallyn <serge at hallyn.com> wrote:

> There are several things under way which will help with this,
>
> 1. unprivileged mounting of squashfs will allow you to just mount it
> in the container
>

I also have the setup working using the lxc.rootfs and lxc.rootfs.mount to
mount the squashfs as a loop device.  Doing it this way, I can avoid the
pre-start hook to mount.  The results within the container are still the
same.  Is this the unprivileged mounting you are talking about?

2. Djalal Harouni is working on a feature to allow shifting uids into
> a container as a mount option.
> 3. jbottomley is working on shiftfs which is a stackable fs which lets
> you shift the uids
>
> But for now, you'd need to chmod the files in the fs into the range
> of the containers.
>
> Quoting Judd Meinders (judd.meinders at rockwellcollins.com):
> > Hello all,
> >
> > I am attempting to run a custom created unprivileged container on ubuntu
> > 16.04.  It is started from the root user using lxc-start and is
> configured
> > with lxc.id_map to assign unprivileged UID/GID for users.
> >
> > The root file system I am trying to use is squashfs, and it has been
> > created with UID/GID starting at 0.  The user and group ownership of
> files
> > within the squashfs is not modifiable due to squashfs being read only.
> >
> > I am using a pre-start hook to mount the squashfs in a location that is
> > accessible by the unprivileged users in lxc.idmap.  Everything seems to
> > work properly at this point.
> >
> > When I attach to the container after starting, all the files are owned by
> > 65534:65534.  When I inspect on the host, they are all owned by UID/GID
> 0.
> > This isn't a problem for anything running as root in the container of
> > course, but if I tried to run something in the container as another
> user, I
> > will have problems.
> >
> > My question is: How can I correct this?  Does anyone know what causes it?
> > Is there an alternate way of mounting the rootfs so that the ownership of
> > the files makes sense in the container?
> >
> > My config:
> >
> > lxc.network.type = veth
> > lxc.network.link = lxcbr0
> > lxc.network.flags = up
> > lxc.network.ipv4 = 10.0.3.2/24
> > lxc.network.hwaddr = 00:16:3e:xx:xx:xx
> > lxc.rootfs =/var/lib/lxc/lxc1/rootfs
> > lxc.haltsignal = SIGUSR1
> > lxc.utsname = lxc1
> > lxc.tty = 1
> > lxc.pts = 1
> > lxc.id_map = u 0 100000 10000
> > lxc.id_map = g 0 100000 10000
> > lxc.cgroup.cpuset.cpus = 0
> > lxc.cgroup.cpu.shares = 179
> > lxc.cgroup.memory.limit_in_bytes = 25600000
> > lxc.cgroup.devices.deny = a
> > lxc.cgroup.devices.allow = c 1:3 rw
> > lxc.cgroup.devices.allow = c 1:8 r
> > lxc.cgroup.devices.allow = c 1:9 r
> > lxc.cap.keep = none
> > lxc.mount.entry = tmpfs /var/lib/lxc/lxc1/rootfs/tmp tmpfs
> > nodev,nosuid,size=3M 0 0
> > lxc.mount.auto = proc:mixed
> > lxc.hook.pre-start = /usr/share/lxc/hooks/mount
> > lxc.aa_profile = unconfined
> >
> > File ownership after attaching:
> >
> > root at user-VirtualBox:/var/lib/lxc/lxc1# lxc-attach -n lxc1
> > / # ls -la
> > total 2
> > drwxrwxr-x   16 65534    65534          261 Jul  5 19:25 .
> > drwxrwxr-x   16 65534    65534          261 Jul  5 19:25 ..
> > drwxr-xr-x    2 65534    65534          980 Jul  6 16:09 bin
> > drwxr-xr-x    4 root     root           360 Jul  6 18:22 dev
> > drwxr-xr-x   10 65534    65534          406 Jul  6 16:09 etc
> > drwxr-xr-x    2 65534    65534          737 Jul  6 16:09 lib
> > lrwxrwxrwx    1 65534    65534            3 Jul  6 16:48 lib32 -> lib
> > lrwxrwxrwx    1 65534    65534           11 Jul  6 16:48 linuxrc ->
> > bin/busybox
> > drwxr-xr-x    2 65534    65534            3 Jan 29 14:00 media
> > drwxr-xr-x    2 65534    65534            3 Jan 29 14:00 mnt
> > drwxr-xr-x    2 65534    65534            3 Jan 29 14:00 opt
> > dr-xr-xr-x  222 65534    65534            0 Jul  6 18:22 proc
> > drwx------    2 65534    65534            3 Jan 29 14:13 root
> > lrwxrwxrwx    1 65534    65534            3 Jul  6 16:48 run -> tmp
> > drwxr-xr-x    2 65534    65534          963 Jul  6 16:09 sbin
> > drwxr-xr-x    2 65534    65534            3 Jan 29 14:00 sys
> > drwxrwxrwt    2 65534    65534            3 Jan 29 14:00 tmp
> > drwxr-xr-x    7 65534    65534          102 Jul  5 16:51 usr
> > drwxr-xr-x    5 65534    65534          121 Jul  6 16:09 var
> > -rw-r--r--    1 65534    65534         1266 Jul  6 16:09 version.platform
> >
> >
> >
> >
> > --
> > Judd Meinders
>
> > _______________________________________________
> > lxc-users mailing list
> > lxc-users at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
>
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users

-- 
Judd Meinders
Sr. Software Security Engineer
e. judd.meinders at rockwellcollins.com
p. 319-263-1875
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160706/a467e5a5/attachment-0001.html>