Red Hat Bugzilla – Bug 1015089
Cannot log into GNOME 3, stuck at gray background after entering password
Last modified: 2013-10-09 10:30:14 EDT
Created attachment 807074 [details] gnome-session output from journalctl during failed login Description of problem: Signing into a GNOME 3 session fails partway through. The password is accepted, but the session startup halts at a gray screen. Version-Release number of selected component (if applicable): gdm-3.10.0-1.fc20.x86_64 gnome-session-3.10.0-1.fc20.x86_64 How reproducible: Every time Steps to Reproduce: 1. Boot the system 2. Log in to a GNOME 3 session with a valid password 3. Actual results: Stuck at a gray screen Expected results: Logged into the session Additional info: I have temporarily switched to using Cinnamon which allows me to log in successfully.
Looking at the journal output, it appears it crashes because the XDG_SESSION_ID environment variable is not set. It should be set by pam_systemd.
Works: sssd-1.11.0-0.3.beta2.fc20 Breaks: sssd-1.11.1-1.fc20 (and later) The journal error that is apparent between the two is: systemd-logind: Failed to create runtime directory /run/user/[$UID]: File exists gdm-password: pam_systemd(gdm-password:session): Faile to create session: File exists Seems like with old sssd we are not creating /run/user/[$UID] and so systemd/logind works as expected. With new sssd that directory is being created before systemd/logind expects and so systemd/logind gets confused... Maybe this is a systemd/logind problem, but the fix for now is to downgrade sssd. My steps to downgrade: yum install -y koji-utils mkdir sssd-downgrade cd sssd-downgrade koji download-build --arch=x86_64 --arch=noarch 453621 yum downgrade * shutdown -r now WIN
Looking at the systemd code, it should be fine if /run/user/[$UID] exists, as long as it has the ownership and permissions it expects, which are: mode=0700, uid=$UID, gid=$PRIMARY_GID_FOR_UID (not completely sure about the last one, guessing from code that refers to 'user->gid')
I just found the same results. SSSD has been creating this directory since SSSD 1.9.0, because we need it earlier than the session phase, but this change in behavior is odd. I'm going to check the SSSD code for why it's creating it with the wrong permissions now. This problem will also disappear soon since we're moving to the kernel keyring instead of using /run/user/UID before F20 officially ships. As a temporary fix, you can also set krb5_ccname_template = FILE:/tmp/krb5cc_%U_XXXXXX in the [domain/DOMAINNAME] section of the sssd.conf which will tell SSSD to use the historical behavior of storing caches in /tmp instead of /run/user/UID. This is what I'm doing while I sort this out.
Ok, with krb5-1.11.3-21.fc20, keyutils-1.5.7-1.fc20, a recent kernel and sssd-1.11.1-1.fc20, the problem goes away (since the default for the system is to use the new KEYRING:persistent:UID ccache type, which doesn't involve this directory creation at all). I'm still going to leave this bug assigned to SSSD, because it's clearly wrong that we're creating /run/user/UID with root ownership and wide-open permissions. I'm not sure why that's happening. I suspect the SSSD answer will be to drop the directory-creation logic entirely, though. It's very flaky. The keyring approach is better in pretty much every way. However, with the other packages in place, the default configuration should be working.
I'm adding Nalin into the mix here, because I think there's an upgrade collision problem we have here with both SSSD and MIT Kerberos. In SSSD 1.11.1, we've changed the built-in default so that if the krb5_ccname_template option hasn't been specified, we will instead use the default_ccache_name parameter from the kerberos profile (which hands us back the exact contents of the default_ccache_name attribute contained in the krb5.conf on the system. Starting with krb5-1.11.3-21.fc20, we are including an explicit default_ccache_name value (specifically, KEYRING:persistent:%{uid} ) into the installed krb5.conf in the krb5-libs package. This means that new installations will always pick up the new KEYRING type. The problem however is that if the krb5.conf was modified on the system before upgrade (which is generally the case for most deployments actually using kerberos, such as when configured by ipa-client, realmd or authconfig), the new version will be installed as krb5.conf.rpmsave. Thus, SSSD 1.11.1 will not pick up the new option and will instead end up using the hard-coded default built into Kerberos (which I *think* on Fedora 19 is DIR:/run/user/%{uid}/krb5cc/). So I'm concerned about how we're going to manage the upgrade here, since we're not properly transitioning people to the new KEYRING cache.
There is a patch on the list to remove the ability to create directory with system wide permissions, but the patch needs revision as currently it breaks unit tests.
This build should fix the creation of krb5 ccache dir with wrong permissions: http://koji.fedoraproject.org/koji/taskinfo?taskID=6023742 There is one non-reviewed patch, but it only touches the unit tests so I hope that's OK in the meantime.
sssd-1.11.1-2.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/sssd-1.11.1-2.fc20
The patches were now acked upstream so I've built the update. Please test and add karma, thank you!
Package sssd-1.11.1-2.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.11.1-2.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18330/sssd-1.11.1-2.fc20 then log in and leave karma (feedback).
sssd-1.11.1-2.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.