[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