[systemd-devel] logind vs CAP_SYS_ADMIN-lessness

Christian Seiler christian at iwakd.de
Thu Jan 22 06:53:12 PST 2015

I've been playing around with systemd on Debian Jessie in
CAP_SYS_ADMIN-less and I came upon the following issue[1]:

Without CAP_SYS_ADMIN, logind is unable to mount a per-user tmpfs to
/run/user/$UID. Relevant journal messages:

systemd-logind[48]: Failed to mount per-user tmpfs directory 
/run/user/600: Operation not permitted
sshd[1357]: pam_systemd(sshd:session): Failed to create session: Access 

The user is still allowed to log in, but there are some unwanted side

  - ls -l /run/user
    total 0
    drwx------ 2 root root 40 Jan 22 15:00 0
    drwx------ 2 root root 40 Jan 22 14:46 600

    Therefore, /run/user/$UID is effectively useless because the
    permissions are wrong (logind aborts after mkdir but before
    mount). Also: lack of cleanup on this error could be considered
    a second (more minor) problem.

  - XDG_RUNTIME_DIR not set (pam_systemd aborts beforehand)

  - user not registered in logind (loginctl doesn't show user)

  - user not put in cgroup (logind aborts before that logic happens),
    they stay in the getty at tty*.service / ssh.service cgroup.

  - probably some more stuff related to this

Obviously, without CAP_SYS_ADMIN you can never mount not even a tmpfs
to /run/user/$UID, so it's clear why it doesn't work.

For now, this is mostly a cosmetic issue for me, because I don't
really need logind functionality in such containers, so it's not a
huge problem for me.

Nevertheless, I think it would be great if this could also be fixed,
because you never know what other applications people might come up

The solution would probably be to just add a code path to chown
the directory instead of mounting a tmpfs on top of it. That doesn't
separate users from root inside the container quite as much, but in
containers without CAP_SYS_ADMIN, I think that's a trade-off that's
worth making.

What do you think?


[1] Note that the only other issue I stumbled upon has now been fixed,
     so in general I would say that systemd already works really well
     in containers without CAP_SYS_ADMIN if you know how to set them
     up properly.

More information about the systemd-devel mailing list