Bug#813789: systemd: su -l does not start/attach to user session

[Boris Kolpackov]

con...@kontesti.me  writes:

> I had the same problem, but I ended up reporting it to login package
> (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814670 should they be
> merged?). I only saw this bug here now.
> 
> Does anyone have, at least, a workaround for this? I'd rather su or sudo into 
> a
> user instead of having to initiate a ssh session to it (this user used to not
> even have a password or SSH key).
> 
> Not even
> 
>   # login -f username
> 
> works.

The only workaround that I know of is:

1. Enable linger for the account.
2. Manually "attach" to the lingering session by:

   export XDG_RUNTIME_DIR=/run/user/`id -u`

I also wonder if that su reimplementation that is part of new systemd
is meant to fix/give control over this.

Bug#813789: systemd: su -l does not start/attach to user session

[Michael Biebl]

Am 02/05/2016 um 10:51 AM schrieb Boris Kolpackov:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
> 
> Hi,
> 
> I keep seeing in various places (Debian-related and otherwise) that
> su does not start a new systemd user session because it is not a
> proper login. The symptom is:
> 
> # su -l boris
> $ systemctl --user status
> Failed to get D-Bus connection: Connection refused
> 
> To me, it seems su -/-l/--login is just like login (what is the
> conceptual difference between su -l boris and ssh boris@127.0.0.1?).
> It also does not attach to a (lingering) user session, unless I
> manually do:

It was pointed out to me via IRC, that what I said so far is most likely
incorrect:

>  mbiebl: su doesn't create new logind sessions.
>  (Nor su -l)
>  It might create one if started outside an existing session, but "su 
> -l", for example, gnome-terminal in a X session doesn't start a new logind 
> session.
>  And just "su" even leaves the broken XDG_RUNTIME_DIR of the original 
> user in the environment.
>  IIRC systemd upstream said that su should not start a new session 
> accroding to POSIX, but I doubt that refers to either PAM or logind sessions, 
> but just to not calling setsid()
>  https://github.com/systemd/systemd/issues/825#issuecomment-127917622
>  pam_systemd is mostly a no-op even if su does call it

That su -l does start a new logind session here (with v228 and under X
only) is probably unexpected behaviour.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#813789: systemd: su -l does not start/attach to user session

[Boris Kolpackov]

Package: systemd
Version: 215-17+deb8u2
Severity: normal

Hi,

I keep seeing in various places (Debian-related and otherwise) that
su does not start a new systemd user session because it is not a
proper login. The symptom is:

# su -l boris
$ systemctl --user status
Failed to get D-Bus connection: Connection refused

To me, it seems su -/-l/--login is just like login (what is the
conceptual difference between su -l boris and ssh boris@127.0.0.1?).
It also does not attach to a (lingering) user session, unless I
manually do:

export XDG_RUNTIME_DIR=/run/user/`id -u`

[Note that in this case XDG_SESSION_ID will still be bogus but
apparently it is harmless since it is for information purposes
only.]

It seems the decision whether it is a proper login or not is
made somewhere in /etc/pam.d/. While looking through the files
I noticed that the runuser-l file in this directory (but not
runuser) contains this line:

-sessionoptionalpam_systemd.so

While this may seem like it should be the solution, runuser -l
still doesn't start/attach to the user session. So the purpose
of this extra line is still a mystery to me.

For completeness, let me mention /usr/share/pam-configs/systemd
which seems related but I am not sure how.


-- Package-specific info:

-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u1
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u2
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u2
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.20-0+deb8u1
ii  libpam-systemd  215-17+deb8u2

Versions of packages systemd suggests:
pn  systemd-ui  

-- no debconf information

Bug#813789: systemd: su -l does not start/attach to user session

[Boris Kolpackov]

Michael Biebl  writes:

> Actually in Debian, su *does* start a logind session. If you look at
> 
> /etc/pam.d/su it includes /etc/pam.d/common-session

It does:

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session


> If libpam-systemd is installed, there will be an entry in common-session
> like this:
> session   optionalpam_systemd.so

libpam-systemd is installed and common-session includes this line (and
it hasn't been modified in any way):

# and here are more per-package modules (the "Additional" block)
session requiredpam_unix.so 
session optionalpam_systemd.so 
# end of pam-auth-update config

> If libpam-systemd is installed and enabled, that should actually work.

No, it does not work. This is Debian stable/Jessie with all the latest
updates installed. I have three identical machines setup like this and
on all three it does not work.


> It's unclear to me, why you filed this as an issue against systemd?

It looked to me like a problem in systemd/libpam-systemd. Do you still
believe I should file it against su (and runuser, and maybe sudo for
good measure)?

Bug#813789: systemd: su -l does not start/attach to user session

[Michael Biebl]

Am 02/05/2016 um 10:51 AM schrieb Boris Kolpackov:
> Package: systemd
> Version: 215-17+deb8u2
> Severity: normal
> 
> Hi,
> 
> I keep seeing in various places (Debian-related and otherwise) that
> su does not start a new systemd user session because it is not a
> proper login. The symptom is:

Actually in Debian, su *does* start a logind session. If you look at

/etc/pam.d/su it includes /etc/pam.d/common-session

If libpam-systemd is installed, there will be an entry in common-session
like this:
session optionalpam_systemd.so

If that line is missing, then most likely common-session had local
modifications and those are preserved by pam-auth-update.

So we *do* start a logind session for both su and su -l. It should
probably only be done for the latter. We could actually argue that this
is a bug in Debian in the su configuration.

Fedora/Redhat differentiate su and su -l and ship different pam configs:
/etc/pam.d/su and
/etc/pam.d/su-l

> # su -l boris
> $ systemctl --user status
> Failed to get D-Bus connection: Connection refused

If libpam-systemd is installed and enabled, that should actually work.


> To me, it seems su -/-l/--login is just like login (what is the
> conceptual difference between su -l boris and ssh boris@127.0.0.1?).
> It also does not attach to a (lingering) user session, unless I
> manually do:
> 
> export XDG_RUNTIME_DIR=/run/user/`id -u`
> 
> [Note that in this case XDG_SESSION_ID will still be bogus but
> apparently it is harmless since it is for information purposes
> only.]
> 
> It seems the decision whether it is a proper login or not is
> made somewhere in /etc/pam.d/. While looking through the files
> I noticed that the runuser-l file in this directory (but not
> runuser) contains this line:
> 
> -sessionoptionalpam_systemd.so

If that is the only file with a pam_systemd line, then libpam-systemd is
either not installed or not enabled due to local modifications in
common-session.

> While this may seem like it should be the solution, runuser -l
> still doesn't start/attach to the user session. So the purpose
> of this extra line is still a mystery to me.
> 
> For completeness, let me mention /usr/share/pam-configs/systemd
> which seems related but I am not sure how.

It's unclear to me, why you filed this as an issue against systemd?
I don't see anything that the systemd package can do about the su
behaviour. su is shipped by the login package.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature