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

[Patrick Toomey]

> 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
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).