[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