[lxc-users] Autostart Unpriviledged Containers

[Fajar A. Nugraha]

On Sat, Oct 10, 2015 at 9:52 PM, Paul Jones <spacefreak18 at gmail.com> wrote:
> Thanks for you answers Fajar. The technology is still in it's infancy, so
> I'm not surprised with the need to abuse sudo in this manner, and am willing
> to work around it.

If everything you tested fail, the sure-fire workaround would be just
to setup passwordless key-based ssh authentication for your user, so
you can do something like

ssh user at localhost lxc-autostart

>
> But i'm not sure I completely follow what you are saying. I get the error
> that you are mentioning from systemd, where it is already running in a
> session. But i can also start the service after boot manually and not get
> that error, and it will create the cgroup, but as usual, i cannot as normal
> user move a process to that cgroup, it get an invalid request error.
>

You don't move your process as a normal user. You get root to create a
cgroup for you (including the correct permission), and use that
(possibly creating a cgroup under that). The easiest way would be to
abuse pam_systemd, which creates
/user.slice/user-X.slice/session-N.scope , where X is uid and N is
session identifier.


>  And I can follow your steps 1-3 already.
>
> My questions are on step 4. My output looks nothing like yours and I do not
> understand why you're moving the current tty into the / cgroup which is
> where it already resides?
>

Does it already reside there?

I haven't tested what cgroup systemd services are put in by default,
but my guess is it's NOT "/".

And when you login as root, you should be on
/user.slice/user-0.slice/session-N.scope cgroup, and pam_systemd will
refuse to create a new cgroup for the normal user if you're already in
a user session (including root's session)


> My output looks like this:
>
> root at ZitZ:/home/paul# bash -c 'cgm movepidabs all / $$ && sudo -u paul -i
> cat /proc/self/cgroup'
> 9:perf_event:/
> 8:memory:/
> 7:cpuset:/
> 6:devices:/
> 5:blkio:/
> 4:cpu,cpuacct:/
> 3:freezer:/
> 2:net_cls,net_prio:/
> 1:name=systemd:/

Then pam_systemd doesn't work.
What's in /var/log/auth.log when you execute the above command?
Did you forget to add entry for pam_loginuid before pam_systemd?
What does "cat /proc/self/cgroup" say when you login as user "paul",
either with ssh or from console?

Again, the goal is NOT to create a new cgroup that a normal user can
"move" into.
Rather, it's to create the SAME cgroup setting that you get when you
LOGIN from ssh/console, where you're already assigned to a cgroup that
you can control, and where a normal user can start an unprivileged
container.

-- 
Fajar