This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1015089 - Cannot log into GNOME 3, stuck at gray background after entering password
Cannot log into GNOME 3, stuck at gray background after entering password
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sssd (Show other bugs)
20
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Jakub Hrozek
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 1014834
  Show dependency treegraph
 
Reported: 2013-10-03 08:45 EDT by Stephen Gallagher
Modified: 2013-10-09 10:30 EDT (History)
14 users (show)

See Also:
Fixed In Version: sssd-1.11.1-2.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-09 10:30:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gnome-session output from journalctl during failed login (21.67 KB, text/x-log)
2013-10-03 08:45 EDT, Stephen Gallagher
no flags Details

  None (edit)
Description Stephen Gallagher 2013-10-03 08:45:11 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.
Comment 1 Giovanni Campagna 2013-10-03 09:22:15 EDT
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.
Comment 2 Eric Paris 2013-10-03 16:06:11 EDT
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
Comment 3 Owen Taylor 2013-10-03 16:09:18 EDT
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')
Comment 4 Stephen Gallagher 2013-10-03 16:12:22 EDT
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.
Comment 5 Stephen Gallagher 2013-10-03 17:13:49 EDT
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.
Comment 6 Stephen Gallagher 2013-10-03 20:25:08 EDT
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.
Comment 7 Jakub Hrozek 2013-10-04 03:19:08 EDT
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.
Comment 8 Jakub Hrozek 2013-10-04 04:36:56 EDT
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.
Comment 9 Fedora Update System 2013-10-04 09:31:49 EDT
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
Comment 10 Jakub Hrozek 2013-10-04 09:36:11 EDT
The patches were now acked upstream so I've built the update. Please test and add karma, thank you!
Comment 11 Fedora Update System 2013-10-04 21:44:11 EDT
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).
Comment 12 Fedora Update System 2013-10-09 10:30:14 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.