[lxc-users] Problems with user sessions inside a Ubuntu Desktop Container

Alain St-Denis alain at zenfolie.org
Tue Feb 9 00:06:06 UTC 2016


Hi,

I was able to work around the issue. There appear to be two reasons why
the polkit authentication agent can't find a user session. First, no
session can be created if /dev/tty0 doesn't exist as per this code in
systemd-204/src/login/logind.c manager_connect_console:

if (access("/dev/tty0", F_OK) < 0) {
    m->console_active_fd = -1;
    return 0;
}

m->console_active_fd must be >= 0 for seat_can_multi_session to return
true. So I simply linked /dev/tty0 to lxc/console in my container. Not
sure this is the right thing to do but sessions are now created...

The second reason is related to this cgroup path duplication business
(as in /lxc/topaze/lxc/topaze/user...). To identify a user's session,
polkit calls sd_pid_get_session which eventually ends up in
cg_path_get_session with "/lxc/topaze/user/..." as the cgroup path.
First thing cg_path_get_session does is check if the cgroup path starts
with "/user" so it returns an error right there. I gave up trying to
understand where this path duplication comes from. This small patch
works around the polkit not finding a session issue:

--- systemd-204-5ubuntu20.16.orig/src/shared/cgroup-util.c
+++ systemd-204-5ubuntu20.16/src/shared/cgroup-util.c
@@ -1621,16 +1621,19 @@ _pure_ static const char *skip_label(con
 }
 
 int cg_path_get_user_unit(const char *path, char **unit) {
-        const char *e;
+        const char *e, *user = NULL;
+
+    cg_get_user_path(&user);
 
         assert(path);
         assert(unit);
+    assert(user);
 
         /* We always have to parse the path from the beginning as unit
          * cgroups might have arbitrary child cgroups and we shouldn't get
          * confused by those */
 
-        e = path_startswith(path, "/user/");
+        e = path_startswith(path, user);
         if (!e)
                 return -ENOENT;
 
@@ -1705,12 +1708,15 @@ int cg_pid_get_machine_name(pid_t pid, c
 
 int cg_path_get_session(const char *path, char **session) {
         const char *e, *n;
-        char *s;
+        char *s, *user = NULL;
+
+    cg_get_user_path(&user);
 
         assert(path);
         assert(session);
+    assert(user);
 
-        e = path_startswith(path, "/user/");
+        e = path_startswith(path, user);
         if (!e)
                 return -ENOENT;
 
@@ -1748,12 +1754,15 @@ int cg_pid_get_session(pid_t pid, char *
 
 int cg_path_get_owner_uid(const char *path, uid_t *uid) {
         const char *e, *n;
-        char *s;
+        char *s, *user = NULL;
+
+    cg_get_user_path(&user);
 
         assert(path);
         assert(uid);
+    assert(user);
 
-        e = path_startswith(path, "/user/");
+        e = path_startswith(path, user);
         if (!e)
                 return -ENOENT;
 
Now, the next challenge is lightdm getting confused trying to do
VT_ACTIVATE when the screenlock kicks in:

Error using VT_ACTIVATE 8 on /dev/console: Inappropriate ioctl for device

At this point my session is lost. If anyone has some insight here,
please share. In the mean time, no screen locking for me. :-)


Le 26 janvier 2016 11:10:08 HNE, Alain St-Denis <alain at zenfolie.org> a
écrit :


    Le 2016-01-26 02:55, Serge Hallyn a écrit :

        Quoting Alain St-Denis (alain at zenfolie.org):

            Hi, I experience the exact same problem. Similar setup (wily
            host, elementary freya container). No user session is
            created when I login the desktop so polkit won't grant
            elevated privileges. In the container, /proc/1/cgroup shows:
            10:cpu,cpuacct:/lxc/topaze 9:freezer:/lxc/topaze
            8:devices:/lxc/topaze 7:memory:/lxc/topaze
            6:cpuset:/lxc/topaze 5:net_cls,net_prio:/lxc/topaze
            4:hugetlb:/lxc/topaze 3:perf_event:/lxc/topaze
            2:blkio:/lxc/topaze 1:name=systemd:/lxc/topaze In the
            container auth.log, I see those lines: Jan 24 15:20:09
            topaze systemd-logind[1739]: cgmanager: cgm_list_children
            for controller=systemd, cgroup_path=lxc/topaze/user failed:
            invalid request Jan 24 15:20:09 topaze systemd-logind[1739]:
            New seat seat0. Jan 24 15:20:09 topaze systemd-logind[1739]:
            Preallocating VTs... Jan 24 15:20:09 topaze
            systemd-logind[1739]: systemd-logind running as pid 1739 Jan
            24 15:20:11 topaze lightdm:
            pam_systemd(lightdm-greeter:session): Failed to create
            session: Invalid argument The container runs cgproxy. On the
            host, cgmanager reports: jan 24 15:20:09 opale
            cgmanager[952]: cgmanager: Invalid path
            /run/cgmanager/fs/none,name=systemd//lxc/topaze/lxc/topaze/user
            (No such file or directory) jan 24 15:20:09 opale
            cgmanager[952]: cgmanager:list_children_main: Could not
            determine the requested cgroup (systemd:lxc/topaze/user) jan
            24 15:20:09 opale cgmanager[952]: cgmanager: Error getting
            children for systemd:lxc/topaze/user for pid 2095 Does
            anybody have a hint on what causes this cgroup path
            duplication (lxc/topaze/lxc/topaze)? I suspect it may have
            something to do with the issue. 

        I don't know what elementary freya is, but maybe this is a bug
        in the systemd package there. Get the cgroxy logs (start it with
        --debug), and see what calls are being made to it. Better yet
        strace the login process (maybe start with the getty or sshd).
        If it is reading the cgroup path from /proc/self/cgroup and then
        using cgmanager to movepid to something based on that, that's
        wrong. 


    Sorry, I should've provided more details. Elementary OS freya is based
    on trusty. It's running with the same pieces of systemd 204-5ubuntu20.15
    trusty runs.

    cgproxy --debug only shows a message corresponding what is logged for
    cgmanager on the host:

    Connection from private client
    ListChildren: Client fd is: 7 (pid=1722, uid=0, gid=0)
    cgproxy:list_children_main: Server encountered an error: bad cgroup?
    Disconnected from private client

    I'm running the current lxc stable ppa in both the host and the container.

    strace on lightdm does show /proc/1/cgroup being opened, but also shows
    /proc/self/cgroup. BTW, being new to this list, what is the proper way
    to attach large outputs?

    Looking at /run/systemd/seats/seat0 in the container I see:

    # This is private data. Do not parse.
    IS_VTCONSOLE=1
    CAN_MULTI_SESSION=0
    CAN_TTY=1
    CAN_GRAPHICAL=0

    which doesn't look right. Something wrong with udev?
    ------------------------------------------------------------------------

    lxc-users mailing list
    lxc-users at lists.linuxcontainers.org
    http://lists.linuxcontainers.org/listinfo/lxc-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160208/320d4e73/attachment.html>


More information about the lxc-users mailing list