[systemd-devel] logind vs CAP_SYS_ADMIN-lessness

[Christian Seiler]

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 
denied

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

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

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?

Regards,
Christian

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