[lxc-users] ID mapping blues (was: Does lxc-execute work with unprivileged containers?)

Serge Hallyn serge.hallyn at ubuntu.com
Fri Feb 27 06:09:47 UTC 2015


Quoting Patrick Toomey (patrick.toomey at github.com):
> > Sounds like a stackable filesystem that remaps file uids would give
> > you what you need.  (I'm not working on one, but several people have
> > expressed a desire for it)
> >
> 
> I'm not sure I would even need something that elaborate. It seems like
> this is happening mostly because it makes sense for init.lxc to work
> this way in the context of a full container with its own rootfs that
> spawns init.lxc to bootstrap everything. It seems like init.lxc is
> fully capable of being started and launching a process without
> assuming it is uid 0. For example:
> 
>   my_user at ubuntu:~$ whoami
>     my_user
>   my_user2ubuntu:~$ /usr/sbin/init.lxc bash
>     init.lxc: utils.c: mount_fs: 159 failed to mount /proc : Operation
> not permitted
>     init.lxc: utils.c: mount_fs: 159 failed to mount /dev/shm :
> Operation not permitted
>   my_user at ubuntu:~$ whoami
>     my_user
> 
> There are a few errors related to mounting, but in general, it seems
> workable. I could be reading things incorrectly, but it looks like
> this is happening in
> https://github.com/lxc/lxc/blob/6a9390e349c5df27d1dec072ef2fb30848a35055/src/lxc/cgmanager.c#L423-L426.
> This function is called from
> https://github.com/lxc/lxc/blob/6a9390e349c5df27d1dec072ef2fb30848a35055/src/lxc/cgmanager.c#L484,
> which is then passed to "userns_exec_1" which is responsible for
> cloning into a new user namespace:
> https://github.com/lxc/lxc/blob/b88ff9a0e33e7220d0c2b7059706c492200e4c2b/src/lxc/conf.c#L4380-L4402.
> 
> While lxc-execute can be used to run a command from a named container,
> it also supports calling a command from the host with "default
> containment". In those situations it doesn't seem like switching uids

Heh, lxc-execute predates user namespaces by about 5 years.

> is what the user would exepect. In other words, if I'm not invoking a
> full container, I would expect a non-root invocation of "lxc-execute
> -n foobar -f myconfig -- whoami" to return the same user
> inside/outside of the container (unless I remapped uids).

A patch to that effect would definately be interesting.


More information about the lxc-users mailing list