[lxc-users] Autostart Unpriviledged Containers

[Paul Jones]

The error i see in auth.log is that i'm already in a session and it cannot
start a session for user paul.

I do believe i setup /etc/pam.d/sudo properly.

paul ~ 12:40:07 $ cat /proc/self/cgroup
9:perf_event:/
8:memory:/
7:cpuset:/
6:devices:/user.slice
5:blkio:/
4:cpu,cpuacct:/
3:freezer:/
2:net_cls,net_prio:/
1:name=systemd:/user.slice/user-1000.slice/session-6.scope

Why isn't it as simple as moving into this cgroup or changing its settings?


On Sat, Oct 10, 2015 at 12:19 PM, Fajar A. Nugraha <list at fajar.net> wrote:

> 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
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
>



-- 
Time To Get an EKG, G!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20151010/85e277e8/attachment.html>