[lxc-devel] lxc-execute failes to exec a command unless you are root.

Patrick Toomey patrick.toomey at github.com
Fri Mar 13 19:40:55 UTC 2015


I ran into what seems like unexpected behavior while playing with
`lxc-execute` and unprivileged containers. It seems that `lxc-execute`
assumes that you are either running a privileged container or are
starting an unprivileged container where root is mapped to some
subordinate IDs. It looks like `lxc-execute` always does a setuid(0)
in https://github.com/lxc/lxc/blob/3b6aebceaf331dd4967f86af0632a3b1cde0120c/src/lxc/start.c#L672
when you invoke a new namespace. Here are two quick examples of
executing `lxc-execute` as my regular user (uid 1000):

  lxc-execute -n foobar -- whoami
  lxc-execute: start.c: must_drop_cap_sys_boot: 554 failed to clone
(0x20000011): Operation not permitted
  lxc-execute: namespace.c: lxc_clone: 67 failed to clone
(0x6c020000): Operation not permitted
  lxc-execute: start.c: lxc_spawn: 897 Operation not permitted -
failed to fork into a new namespace
  lxc-execute: start.c: __lxc_start: 1087 failed to spawn 'foobar'


In that case the command fails to run at all (I'm assuming this has
something to do with the setuid(0) and me not being root. If I
explicitly pass a uid/gid map like below (it maps my host uid to the
container uid and maps the host root to a subordinate ID)  I at least
get the command to execute:


  cat .config/lxc/default.conf
  lxc.id_map = u 1000 1000 1
  lxc.id_map = g 1000 1000 1
  lxc.id_map = u 0 100000 1
  lxc.id_map = g 0 100000 1



  lxc-execute -n foobar -f ~/.config/lxc/default.conf -- whoami
  lxc-execute: conf.c: lxc_execute_bind_init: 3925 Permission denied -
Failed to create mount target
'/usr/lib/x86_64-linux-gnu/lxc/init.lxc.static'
  lxc: cgmanager.c: lxc_cgmanager_escape: 314 call to
cgmanager_move_pid_abs_sync(name=systemd) failed: Escape request from
different namespace requires a proxy
  init.lxc: log.c: log_open: 184 failed to open log file
"/home/ptoomey3/.local/share/lxc/foobar/foobar.log" : Permission
denied
  init.lxc: log.c: log_open: 184 failed to open log file
"/var/log/lxc/foobar.log" : Permission denied
  root

But, as can be seen from the the "root" outpt, this container is
executing `whoami` as container uid 0. This seems pretty unexpected.
If I mapped my host uid 1000 to the container uid 1000 I would expect
`whoami` to return the user that executed `lxc-execute`. It seems like
this may be an artifact of the fact that `init.lxc` is used to launch
the passed in executable. It looks like `init.lxc` is set to uid 0 in
https://github.com/lxc/lxc/blob/3b6aebceaf331dd4967f86af0632a3b1cde0120c/src/lxc/start.c#L672.
This makes sense from the "full container" perspective, since init is
always uid 0 and is responsible for staring up the system. But, for
the case of using `lxc-execute` to invoke a host command using
"default isolation", it seems unexpected. So, I wonder if it should
detect the context it is being invoked from and do the right thing. I
made a quick change to
https://github.com/lxc/lxc/blob/3b6aebceaf331dd4967f86af0632a3b1cde0120c/src/lxc/start.c#L672
and just commented out the line. That ended up doing what I expected.
It successfully launched `whoami` with my original uid being returned
from within the container. But, given that the `setuid(0)` [has a
comment](https://github.com/lxc/lxc/blob/3b6aebceaf331dd4967f86af0632a3b1cde0120c/src/lxc/start.c#L663-L664)
that implies this call is required for the parent to have "privilege
over our namespace", I don't want to assume that the change is that
simple. In other words, I don't have a full appreciation for what code
after that invocation assumes/relies on the parent being uid 0.

So, what do you all think would be necessary for `lxc-execute` to
properly support unprivileged containers? My expectation would be that
a non-root user should be able to execute `lxc-execute -n foobar --
some_utility` and have it execute as their UID with some default
isolation applied. If the changes necessary to support unprivileged
`lxc-execute` are fairly targeted I could take a pass at making the
updates. I was hesitant to start poking around without someone more
familiar with the codebase providing some guidance on what would need
to be updated.


This is related to an issue already posted on GitHub:
https://github.com/lxc/lxc/issues/417 and a comment I posted in
https://github.com/lxc/lxc/issues/417#issuecomment-76493507.


More information about the lxc-devel mailing list