Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
Thanks for the very fast reply :) On Thu, 8 Mar 2018, Michael Biebl wrote: Are you logging in via serial console as unprivileged user? Yes. If I'm root, that grants all access and the session/tty/etc. become irrelevant. But I want to run something as not-root under systemd-inhibit. Yes, I could sudo systemd-inhibit sudo -u ... but blech :) /etc/securetty (pam_securetty) is not really a good idea. Any thoughts why, other than that the default version of that file seems to have everything under the sun listed in it? That all said, you should really take this up with upstream at https://github.com/systemd/systemd/issues ACK, though systemd's official policy is basically "go away if you aren't running the bleeding edge". I can verify the problem code is in the git master of systemd, but their policy is to not accept bug reports from such "old" versions as Debian runs, and explicitly to redirect back to the linux distro for support. Nevertheless, filed https://github.com/systemd/systemd/issues/8582 -- -Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
On Wed, 07 Mar 2018 19:05:13 -0500 Matthew Gabeler-Leewrote: > Package: libpam-systemd > Version: 232-25+deb9u1 > Severity: normal > > Various policykit actions that flag as for "active" or even "inactive", but > not "any", do not work from serial console sessions. After much pain, I'm > fairly sure I've traced this down to libpam-systemd not marking serial > logins as part of a seat. This causes policykit to decide that the session > is not local, and thus its activity state is irrelevant for the > allow_inactive / allow_active policykit grants. Are you logging in via serial console as unprivileged user? > This seems to boil down, finally, to the get_seat_from_display function in > pam_systemd.c. > > Granted, serial console sessions are not _always_ local, given that I guess > modems still technically exist and you might have dialup sessions, but this > basically means that policykit is half-broken on headless systems, and that > breaks significant bits of systemd, such as systemd-inhibit, which is where > I began this adventure. > > For headless systems, being able to identify serial consoles that _are_ > local and thus should have a "seat" would be helpful. The contents of > /etc/securetty seem like they would be a useful starting place here. /etc/securetty (pam_securetty) is not really a good idea. That all said, you should really take this up with upstream at https://github.com/systemd/systemd/issues -- 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#892302: libpam-systemd: Does not recgonize serial consoles as part of a seat
Package: libpam-systemd Version: 232-25+deb9u1 Severity: normal Various policykit actions that flag as for "active" or even "inactive", but not "any", do not work from serial console sessions. After much pain, I'm fairly sure I've traced this down to libpam-systemd not marking serial logins as part of a seat. This causes policykit to decide that the session is not local, and thus its activity state is irrelevant for the allow_inactive / allow_active policykit grants. This seems to boil down, finally, to the get_seat_from_display function in pam_systemd.c. Granted, serial console sessions are not _always_ local, given that I guess modems still technically exist and you might have dialup sessions, but this basically means that policykit is half-broken on headless systems, and that breaks significant bits of systemd, such as systemd-inhibit, which is where I began this adventure. For headless systems, being able to identify serial consoles that _are_ local and thus should have a "seat" would be helpful. The contents of /etc/securetty seem like they would be a useful starting place here. -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable-debug'), (500, 'stable-debug'), (500, 'testing'), (490, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libpam-systemd depends on: ii dbus1.10.24-0+deb9u1 ii libc6 2.26-6 ii libpam-runtime 1.1.8-3.6 ii libpam0g1.1.8-3.6 ii libselinux1 2.6-3+b3 ii systemd 232-25+deb9u1 ii systemd-sysv232-25+deb9u1 libpam-systemd recommends no packages. libpam-systemd suggests no packages. -- no debconf information