Hello!
After a Fedora 23 installation, users can't log in with sddm. A "login failed" message is displayed by sddm, sometimes preceded by a short switch to the tty and back. Users can log into a text console just fine. Also starting a Plasma desktop using startx works perfectly fine.
Because sddm's logs report helper failures with codes 2 and 15, I tried this:
# cp -a /usr/libexec/sddm-helper /usr/libexec/sddm-helper-binary # cat > /usr/libexec/sddm-helper <<-WRAPPER #!/bin/bash strace -f /usr/libexec/sddm-helper-binary "$@" 2>/tmp/sddm WRAPPER
Here's the entire strace output obtained from a login attempt using the wrapper above: https://andrej.podzimek.org/dell-strace-0.txt The strace dump shows (among other glitches) something like a file descriptor leak. But the most important thing seems to be the following:
[pid 1818] execve("/usr/sbin/unix_chkpwd", ["/usr/sbin/unix_chkpwd", "andrej", "nullok"], [/* 0 vars */]) = -1 EPERM (Operation not permitted) [pid 1820] execve("/usr/sbin/unix_chkpwd", ["/usr/sbin/unix_chkpwd", "andrej", "nullok"], [/* 0 vars */]) = -1 EPERM (Operation not permitted)
I tried to make /etc/shadow readable, but that didn't help. Also tried to do setenforce 0 and that didn't help either. :( Last but not least, rebooting with SELinux in permissive mode does away with the EPERM error, but sddm logins hang forever, with no chance to retry.
I looked at recent sddm bugs such as this one: https://bugzilla.redhat.com/show_bug.cgi?id=1265813 But I don't think other sddm issues could be directly related, because the failure pattern is different, i.e., I can't see any segfaults here and my user IDs are in the correct range (uid 1001 in the attached log). :(
What's wrong here? Why does sddm fail on Fedora 23? The hardware, just if it happens to matter: DMI: Dell Inc. Inspiron 7548/0AM6R0, BIOS A00 11/19/2014
Cheers, Andrej
After a Fedora 23 installation, users can't log in with sddm. A "login failed" message is displayed by sddm, sometimes preceded by a short switch to the tty and back.
Anything recorded in these users' ~/.xsession-errors ?
No. :-( Nothing at all, it's empty. (Yeah, that was the first thing I checked.) Also "audit2allow -b" doesn't show anything related to sddm. But KDE works and starts just fine using startx.
Andrej
After a Fedora 23 installation, users can't log in with sddm. A "login failed" message is displayed by sddm, sometimes preceded by a short switch to the tty and back.
Anything recorded in these users' ~/.xsession-errors ?
No. :-( Nothing at all, it's empty. (Yeah, that was the first thing I checked.) Also "audit2allow -b" doesn't show anything related to sddm. But KDE works and starts just fine using startx.
I've just tried Plasma 5 Wayland, but the outcome was even worse, because I ended up with a black screen and no way to switch consoles. The log messages are still the same, sddm-helper exits with error codes 2 or 15. Running sddm with --test-mode doesn't work at all, it just hanges right away.
So sddm is unusable on Fedora 23. (That's odd, because it works just fine for me on Arch.) What alternatives could I try? Is there a working display manager compatible with KDE 5?
Andrej
After a Fedora 23 installation, users can't log in with sddm. A "login failed" message is displayed by sddm, sometimes preceded by a short switch to the tty and back.
Anything recorded in these users' ~/.xsession-errors ?
No. :-( Nothing at all, it's empty. (Yeah, that was the first thing I checked.) Also "audit2allow -b" doesn't show anything related to sddm. But KDE works and starts just fine using startx.
I've just tried Plasma 5 Wayland, but the outcome was even worse, because I ended up with a black screen and no way to switch consoles. The log messages are still the same, sddm-helper exits with error codes 2 or 15. Running sddm with --test-mode doesn't work at all, it just hanges right away.
So sddm is unusable on Fedora 23. (That's odd, because it works just fine for me on Arch.) What alternatives could I try? Is there a working display manager compatible with KDE 5?
I got a bit closer to the root cause of the problem: SDDM works and logs me in when I start it by simply running 'sddm' from a root shell. But it fails (with the symptoms described in this thread) when started using systemd.
In what way can systemd be hurting sddm so that it can't log users in?
Andrej
On 12/19/2015 11:30 AM, Andrej Podzimek wrote:
I got a bit closer to the root cause of the problem: SDDM works and logs me in when I start it by simply running 'sddm' from a root shell. But it fails (with the symptoms described in this thread) when started using systemd.
In what way can systemd be hurting sddm so that it can't log users in?
Two thoughts: first, after it fails, log into a CLI and run this:
systemctl status sddm
because that may well answer your question. Second, try disabling the sddm.service and running sddm from rc.local instead.
I got a bit closer to the root cause of the problem: SDDM works and logs me in when I start it by simply running 'sddm' from a root shell. But it fails (with the symptoms described in this thread) when started using systemd.
In what way can systemd be hurting sddm so that it can't log users in?
Two thoughts: first, after it fails, log into a CLI and run this:
systemctl status sddm
Compared to the strace wrapper I tried, combined with a careful inspection of logs from journalctl, status doesn't say too much:
Dec 19 21:41:25 prdell.localdomain systemd[1]: Started Simple Desktop Display Manager. Dec 19 21:41:25 prdell.localdomain systemd[1]: Starting Simple Desktop Display Manager... Dec 19 21:41:27 prdell.localdomain sddm-helper[1893]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0) Dec 19 21:41:31 prdell.localdomain sddm-helper[1945]: pam_kwallet5(sddm:auth): (null): pam_sm_authenticate Dec 19 21:41:31 prdell.localdomain sddm-helper[1945]: pam_kwallet(sddm:auth): (null): pam_sm_authenticate Dec 19 21:41:31 prdell.localdomain sddm[1880]: Oops, secure memory pool already initialized Dec 19 21:41:31 prdell.localdomain sddm-helper[1945]: pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred Dec 19 21:41:31 prdell.localdomain sddm-helper[1945]: pam_kwallet(sddm:setcred): pam_kwallet: pam_sm_setcred Dec 19 21:41:31 prdell.localdomain sddm[1880]: Auth: sddm-helper exited with 2 Dec 19 21:41:32 prdell.localdomain sddm-helper[1970]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)
The sddm-helper exits with error code 2, quite likely due to the EPERM I saw in the strace logs. And as already mentioned, setting SELinux to permissive makes sddm just hang silently.
Second, try disabling the sddm.service and running sddm from rc.local instead.
That fails exactly the same way, which is no surprise, because rc.local is just yet another systemd service. There's indeed something in the environment set up by systemd that sddm just can't tolerate. I'm still not sure what this could be.
What extra restrictions does systemd impose, when compared to running stuff from a root shell? It has its own ulimit settings in /etc/systemd/system.conf, but sddm still fails the same way, with "vanilla" ulimit settings as well as with a relaxed vesion thereof.
Also tried to set PrivateTmp=true in sddm's unit file, just to check this out, but no, still the same problem. :-(
Andrej
systemctl status sddm
Compared to the strace wrapper I tried, combined with a careful inspection of logs from journalctl, status doesn't say too much:
Dec 19 21:41:25 prdell.localdomain systemd[1]: Started Simple Desktop Display Manager. [...] Dec 19 21:41:31 prdell.localdomain sddm[1880]: Auth: sddm-helper exited with 2 Dec 19 21:41:32 prdell.localdomain sddm-helper[1970]: pam_unix(sddm-greeter:session): session opened for user sddm by (uid=0)The sddm-helper exits with error code 2, quite likely due to the EPERM I saw in the strace logs. And as already mentioned, setting SELinux to permissive makes sddm just hang silently.
Second, try disabling the sddm.service and running sddm from rc.local instead.
That fails exactly the same way, which is no surprise, because rc.local is just yet another systemd service. There's indeed something in the environment set up by systemd that sddm just can't tolerate. I'm still not sure what this could be.
What extra restrictions does systemd impose, when compared to running stuff from a root shell? It has its own ulimit settings in /etc/systemd/system.conf, but sddm still fails the same way, with "vanilla" ulimit settings as well as with a relaxed vesion thereof.
Also tried to set PrivateTmp=true in sddm's unit file, just to check this out, but no, still the same problem. :-(
So here are the system logs generated by "journalctl -f" during a login attempt: https://andrej.podzimek.org/loginjournal.txt
They capture (1) an unsuccessful authentication attempt where unix_chkpwd cannot be used by sddm-helper (!), then (2) a quick switch to a text console and back to sddm and finally (3) the opening of a new session for the sddm user and getting back to the sddm console. There are SELinux glitches in (1) and (3).
As already said, disabling SELinux doesn't help, it just makes sddm hang in (1) above. (And there are still obvious file descriptor leaks in sddm, shown by the strace I posted earlier in this thread. It uses up all the 1024 descriptors. You increase the limit to 16384 and it uses 16384, just like that.)
This is utterly frustrating. :-( I'd like to understand what's wrong here. Does anyone have a working sddm that logs users into KDE 5 with SELinux enabled on Fedora 23? If so, what log messages does it produce? Perhaps this could help me filter out the benign messages and focus on those that matter.
Cheers, Andrej
So here are the system logs generated by "journalctl -f" during a login attempt: https://andrej.podzimek.org/loginjournal.txt
They capture (1) an unsuccessful authentication attempt where unix_chkpwd cannot be used by sddm-helper (!), then (2) a quick switch to a text console and back to sddm and finally (3) the opening of a new session for the sddm user and getting back to the sddm console. There are SELinux glitches in (1) and (3).
As already said, disabling SELinux doesn't help, it just makes sddm hang in (1) above. (And there are still obvious file descriptor leaks in sddm, shown by the strace I posted earlier in this thread. It uses up all the 1024 descriptors. You increase the limit to 16384 and it uses 16384, just like that.)
This is utterly frustrating. :-( I'd like to understand what's wrong here. Does anyone have a working sddm that logs users into KDE 5 with SELinux enabled on Fedora 23? If so, what log messages does it produce? Perhaps this could help me filter out the benign messages and focus on those that matter.
Phew, problem solved!
Don't mount /etc with nosuid. :-)
Andrej
Andrej Podzimek wrote:
This is utterly frustrating. :-( I'd like to understand what's wrong here. Does anyone have a working sddm that logs users into KDE 5 with SELinux enabled on Fedora 23? If so, what log messages does it produce?
Yes.
audit logs?
Dec 21 11:13:54 localhost audit: USER_AUTH pid=2271 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=pam_unix,pam_kwallet5,pam_kwallet acct="rdieter1" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' Dec 21 11:13:54 localhost audit: USER_ACCT pid=2271 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="rdieter1" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' Dec 21 11:13:54 localhost audit: CRED_ACQ pid=2271 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix,pam_kwallet5,pam_kwallet acct="rdieter1" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=? res=success' Dec 21 11:13:54 localhost audit: USER_ROLE_CHANGE pid=2271 uid=0 auid=1000 ses=3 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='pam: default- context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 selected- context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=:0 res=success' Dec 21 11:13:54 localhost audit: USER_AVC pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='Unknown permission start for class system exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Dec 21 11:13:54 localhost systemd-logind: New session 3 of user rdieter1. Dec 21 11:13:54 localhost systemd: Started Session 3 of user rdieter1. Dec 21 11:13:54 localhost systemd: Starting Session 3 of user rdieter1. Dec 21 11:13:55 localhost audit: USER_START pid=2271 uid=0 auid=1000 ses=3 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_selinux,pam_loginuid,pam_selinux,pam_keyinit,pam_namespace,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_kwallet5,pam_kwallet,pam_lastlog acct="rdieter1" exe="/usr/libexec/sddm-helper" hostname=? addr=? terminal=:0 res=success'
On 12/19/2015 2:05 PM, Andrej Podzimek wrote:
After a Fedora 23 installation, users can't log in with sddm. A "login failed" message is displayed by sddm, sometimes preceded by a short switch to the tty and back.
Anything recorded in these users' ~/.xsession-errors ?
No. :-( Nothing at all, it's empty. (Yeah, that was the first thing I checked.) Also "audit2allow -b" doesn't show anything related to sddm. But KDE works and starts just fine using startx.
I've just tried Plasma 5 Wayland, but the outcome was even worse, because I ended up with a black screen and no way to switch consoles. The log messages are still the same, sddm-helper exits with error codes 2 or 15. Running sddm with --test-mode doesn't work at all, it just hanges right away.
So sddm is unusable on Fedora 23. (That's odd, because it works just fine for me on Arch.) What alternatives could I try? Is there a working display manager compatible with KDE 5?
Andrej
KDM is still available in KDE F23. I use it because I have to be able to configure the login screen, and I didn't find anyway of doing that with SDDM.
Andrej Podzimek wrote:
After a Fedora 23 installation, users can't log in with sddm. A "login failed" message is displayed by sddm, sometimes preceded by a short switch to the tty and back.
Anything recorded in these users' ~/.xsession-errors ?
No. :-( Nothing at all, it's empty. (Yeah, that was the first thing I checked.) Also "audit2allow -b" doesn't show anything related to sddm. But KDE works and starts just fine using startx.
I've just tried Plasma 5 Wayland,
yeah, plasma wayland support through dm's is at best a tech-preview and virtually untested. Not ready for any real use yet (in fedora at least)
-- Rex
-
Andrej Podzimek -
Joe Zeff -
Lester Petrie -
Rex Dieter