Hello! This post is related to an already long thread I started on users@ -- https://lists.fedoraproject.org/pipermail/users/2015-December/467426.html However, I thought I'd better ask for a few debugging tips here as well. In a nutshell, * text console login and startx work fine, so does KDE 5. * when sddm is started from a root shell, users log in just fine. * when sddm is started from systemd, it can't log users in. There's something about the environment set up by systemd that sddm can't tolerate. And there are a few SELinux glitches in the logs. Here's an output from "journalctl -f" during an unsuccessful login attempt (sddm started by systemd): https://andrej.podzimek.org/loginjournal.txt It captures how sddm can't open the user's session for some reason, then it blips into a text console and back and restores its login console again. With permissive mode or after setenforce 0, sddm just hangs with the password input field greyed out and stays that way forever. Which makes it unclear whether SELinux is indeed to blame here... I've (of course) tried .autorelabel, a recursive restorecon on /home, new and empty user directories, setenforce 0, permissive mode etc., but that just doesn't help. What's wrong here? Any ideas?
I found a solution. It's just that /etc must not be mounted with nosuid. On my systems I usually have /etc in a Btrfs subvolume for easy snapshotting and therefore it's tempting to set a few extra mount options for it. I use nodev on most filesystems other than / and also nosuid for most of them. For some reason /etc on Fedora must not be nosuid, or else systemd runs sddm in a crippled state. Furthermore, switching off nosuid for /var reduced the number of error messages in the logs even further, this time with no user-facing changes though. Allright, that's it, sorry for the noise. Hopefully this will save someone a few days of frustration. :-) Andrej -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/selinux@xxxxxxxxxxxxxxxxxxxxxxx
