4

The current implementation of the LXC technology deals nicely with an issue of starting the privileged containers upon system start.. Users of the unprivileged containers (which arguably promise better security) don't get any working out-of-the-box solution for autostarting their containers.

I know of two ways of achieving this goal. I need to decide which one to take (or maybe there is another?)

Both methods require that the lxc.start.auto 1 be set in the configuration file.

Transforming an existing privileged container

In short one must grant range of subuids to root and chmod o+x permission to /var/lib/lxc.

Invoking unprivileged container via a custom upstart job

The lxc-autostart command invoked by the owner of the unprivileged containers (without the sudo) starts all the unprivileged auto-start containers. The problem is only with how to run it during system startup.

This is tough, because any form of sudo -u <lxc-user> -- lxc-autostart nor su -l <lxc-user> -c lxc-autostart wouldn't work - I guess they don't handle ranges of subuid well. The only way to get root autostarting user's containers is through ridiculously complex ssh <lxc-user>@localhost lxc-autostart. I haven't tried the setgid and setuid stanzas yet (something tells me, it wouldn't work either). EDIT: My intuition was right. Setting the setgid and setuid in upstart script doesn't help either.

Adam Ryczkowski
  • 720
  • 1
  • 9
  • 29
  • I was using the `uidmapshift` approach outlined under your first heading. It worked fine. – 0xC0000022L May 17 '15 at 14:14
  • 1
    I found what's different if you use `su`/`sudo` instead of ssh: check the file `/proc/self/cgroup`. The reason must be somewhere around PAM, namely libpam-systemd. I wrote something about this here: https://askubuntu.com/questions/623789/problem-setting-up-a-user-space-lxc-container – Daniel Alder May 23 '15 at 12:07

0 Answers0