sddm cannot use unix_chkpwd and fails to log users in

[Andrej Podzimek]

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?

Cheers,
Andrej

[Andrej Podzimek]

>  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