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

Serge Hallyn serge.hallyn at ubuntu.com
Tue Feb 9 00:58:35 UTC 2016


Quoting Alain St-Denis (alain at zenfolie.org):
> 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:

Guido, does this by chance work for you too?

> --- 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
> 

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



More information about the lxc-users mailing list