FS#55964 - [systemd] 235-1 logind fails on opening graphical session
Attached to Project:
Arch Linux
Opened by Jürgen Sauer (jojoax) - Thursday, 12 October 2017, 13:12 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 16:44 GMT
Opened by Jürgen Sauer (jojoax) - Thursday, 12 October 2017, 13:12 GMT
Last edited by Dave Reisner (falconindy) - Saturday, 05 January 2019, 16:44 GMT
|
Details
Description:
After System upgrading (2017-10-12) systemd-235.0-1-x86_64.pkg.tar.xz no user X11 Usersesion login was possible. Plasma, XFCE4, Gnome failed, by thorwing a copnnect problem to dbus. "Could not sync environment to dbus" Displaymanager which was used: lightdm Additional info: * package version(s): systemd-235.0-1-x86_64.pkg.tar.xz * config and/or log files etc. Config is: /home is mounted from NFS V4 Server, User database is NIS (ypbind-mt), Special Dirs in $HOME are mounted localy using a btrfs subvolume from the root ssd harddisk. root@pc6:~# systemctl status lightdm.service ● lightdm.service - Light Display Manager Loaded: loaded (/usr/lib/systemd/system/lightdm.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2017-10-12 14:53:59 CEST; 26s ago Docs: man:lightdm(1) Main PID: 992 (lightdm) Tasks: 14 (limit: 4915) CGroup: /system.slice/lightdm.service ├─ 992 /usr/bin/lightdm ├─1009 /usr/lib/xorg-server/Xorg :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch ├─1019 lightdm --session-child 13 16 └─1030 /usr/bin/gnome-keyring-daemon --daemonize --login Okt 12 14:53:59 pc6 systemd[1]: Starting Light Display Manager... Okt 12 14:53:59 pc6 systemd[1]: Started Light Display Manager. Okt 12 14:54:00 pc6 lightdm[992]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Okt 12 14:54:00 pc6 lightdm[1019]: pam_succeed_if(lightdm-autologin:auth): requirement "user ingroup autologin" was met by user "jojo" Okt 12 14:54:00 pc6 lightdm[1019]: gkr-pam: no password is available for user Okt 12 14:54:00 pc6 lightdm[992]: g_object_unref: assertion 'G_IS_OBJECT (object)' failed Okt 12 14:54:00 pc6 lightdm[1019]: pam_unix(lightdm-autologin:session): session opened for user jojo by (uid=0) Okt 12 14:54:25 pc6 lightdm[1019]: pam_systemd(lightdm-autologin:session): Failed to create session: Connection timed out Okt 12 14:54:25 pc6 lightdm[1019]: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files Also on Session startup the tmpfs mount for /run/user/$UID is missing. journalctl -xe shows: Okt 12 14:54:25 pc6 lightdm[1019]: pam_systemd(lightdm-autologin:session): Failed to create session: Connection timed out Okt 12 14:54:25 pc6 lightdm[1019]: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files Okt 12 14:54:27 pc6 ksplashqml[1057]: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-jojo' Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:88: ReferenceError: bottomRect is not defined Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:89: ReferenceError: bottomRect is not defined Okt 12 14:54:27 pc6 ksplashqml[1057]: file:///usr/share/plasma/look-and-feel/org.kde.oxygen/contents/splash/Splash.qml:88: ReferenceError: bottomRect is not defined Steps to reproduce: 1. Get Home from company server (here a Debian V9 exporting /home the classical, refer arch wiki) server:/home /home nfs nofail,_netdev,x-systemd.requires=network-online.target,x-systemd.device-timeout=1 0 0 server:/srv/pkg /var/cache/pacman/pkg nfs nofail,_netdev,x-systemd.requires=network-online.target,x-systemd.device-timeout=1 0 0 2. mount User special directories like (this was done due performance issues with kde and thunderbird) LABEL=pc6root /home/jojo/.config btrfs _netdev,subvol=jojo/config,rw,relatime,space_cache,ssd_spread,ssd,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0 LABEL=pc6root /home/jojo/.local btrfs _netdev,subvol=jojo/local,rw,relatime,space_cache,discard,ssd,ssd_spread,compress=lzo,x-systemd.requires=remote-fs.target 0 0 LABEL=pc6root /home/jojo/.cache btrfs _netdev,subvol=jojo/cache,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0 LABEL=pc6root /home/jojo/.kde btrfs _netdev,subvol=jojo/kde,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0 LABEL=pc6root /home/jojo/.kde4 btrfs _netdev,subvol=jojo/kde4,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0 LABEL=pc6root /home/jojo/.thunderbird btrfs _netdev,subvol=jojo/email,rw,relatime,space_cache,ssd,ssd_spread,discard,compress=lzo,x-systemd.requires=remote-fs.target 0 0 3- Install NIS Environment to get user auth via nis (refer arch wiki) - use lightdm and try to login with any user with a standard user session, which is using dbus like plasma, xfce, gnome ... creating the session fails here at 3 systems. After downgrading to root@pc6:/var/cache/pacman/pkg# pacman -U systemd-234.11-9-x86_64.pkg.tar.xz systemd-sysvcompat-234.11-9-x86_64.pkg.tar.xz Everything was working again. Bug was classified by mine "critical" due no usefull workig or using the system is possible. |
This task depends upon
Closed by Dave Reisner (falconindy)
Saturday, 05 January 2019, 16:44 GMT
Reason for closing: Won't fix
Additional comments about closing: Necessary workarounds should be documented, but we're not going to revert the sandboxing just for a minority of users who need NIS/LDAP support for login.
Saturday, 05 January 2019, 16:44 GMT
Reason for closing: Won't fix
Additional comments about closing: Necessary workarounds should be documented, but we're not going to revert the sandboxing just for a minority of users who need NIS/LDAP support for login.
https://github.com/systemd/systemd/issues/7074
Looks like a confirmation was received there from 3rd party side.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625
Critical means boot failure or system crash, if I am reading this correctly laggy login with NIS users and failure to start a GUI is not quite as severe.
According to the bugreport, "IPAddressDeny=any" in systemd-logind.service can be commented out to fix things.
Critcal is correct, because this is a mature boot failure.
Even here no login, even for "root" is possible and no services are running correctly.
This is a mature boot failure.
Ah, and btw the logind failure (without "IPAddressDeny" commented out) in the actual state leads to a systemd watchdog reset after 3 minutes of the whole machine which is fairly critical in my opinion...
https://github.com/systemd/systemd/issues/7074
Without any hints to this behavior many things are broken. i.E. Login into such a system at all.
Without any hint to this catastrophic changes it results like denial of service attack.
If such a change is nessesary it must be mentioned onto a well seen announcement, not like a secret way like it came into the system.
We administrators here are not personally see, why it was nessessary to disable any login possibility like it was done here.
Yes, that's often how undocumented changes upstream are discovered -- users report them to bug trackers. I appreciate you taking that step.
> We administrators here are not personally see, why it was nessessary to disable any login possibility like it was done here.
Upstream acknowledges the change, gave you the rationale for the change and why it won't be reverted, and offered a workaround.
It's unlikely that Arch will change anything here.
Yep, that's the point. Only lokal root can safely log in to such a borked machine. And nscd is another daemon brought in without any reason other than not to change systemd's behaviour. One potential hole closed, another opened. I prefer changing the default behaviour. But that's everyone's own choice.
And what's the argument against a news item?
Also, this "feature" is broken inside containers. I have an archlinux host which is a nis client and an archlinux container, also a client within the same domain. Both use the same nsswitch.conf (that has nis entries). Yet, the container is working perfectly with the default logind.service while the host fails to log users in.
1. Nscd will not work in general because AFAIU it doesn't support automounter maps which can be exported by the NIS server;
2. You don't need to disable IP sandbox globally. For example, setting IPAddressAllow=localhost and IPAddressAllow=<your.nis.server.ip> in systemd-logind.service.d/ip.conf (either in /etc or /usr/lib) will restore the old behavior.
EDIT: I don't think that there is anything to be fixed in the systemd package because the completely locked down IP sandbox makes sense for most users, and administrators who deal with central auth will configure things in a tailored way...
Sorry, the suggested solution does not work:
root@pc6:/etc/systemd/system# cat /etc/systemd/system/systemd-logind.service.d/ip.conf
IPAddressAllow=localhost
IPAddressAllow=192.168.11.10
IPAddressAllow=192.168.11.0/24
Gives a negative result:
# systemctl status systemd-logind.service
[...]
Dez 06 10:28:44 pc6 systemd[1]: /etc/systemd/system/systemd-logind.service.d/ip.conf:1: Assignment outside of section. Ignoring.
Dez 06 10:28:44 pc6 systemd[1]: /etc/systemd/system/systemd-logind.service.d/ip.conf:2: Assignment outside of section. Ignoring.
Dez 06 10:28:44 pc6 systemd[1]: /etc/systemd/system/systemd-logind.service.d/ip.conf:3: Assignment outside of section. Ignoring.
[...]
And for Adminstrators there must be an correct documentation, which is completely missing.
[Service]
IPAddressAllow=...
See how IPAddressDeny enters systemd-logind.service.
A better admin's doc would be great.
At this time in man pages is nothing usable to read about. Also google give a great silence about.
Like a naural law, the right doc is the latest thing a developer thinks about (As here :) )