> 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