GDM hangs when home directory is inaccessible

Question

I have setup a OpenSUSE 12.3 workstation with SSO through KRB5 and LDAP.

This works pretty smoothly up to the point where GDM isn't very happy about that fact that it cannot access user's home directories that are actually nfs mounts with krb5p.

If no home directory is mounted GDM works fine. If at least one home directory is mounted then GDM will crash when attempting to open the greeter / login screen.

If I remove LDAP (sss) from /etc/nsswitch.conf then GDM will work fine even if the home directories are mounted.

At first I used to have the nfs mount in fstab for /home/users. There GDM would crash every time. Then I have tried to switch to autofs to mount /home/users/* individually. There GDM would work at first but crash thereafter (when the user logs out). Now I have configured it to use pam_mount so that the home directories would get unmounted after a user logs out. Now GDM works as long as there is no other user logged on to the system.

So the problem must be somehow related to the fact that if the user gdm that the GDM greeter uses tries to access any of the mounted home directories, its permission will be denied by the nfs server due to a missing kerberos ticket. Even root cannot access these directories.

Any attempt to give GDM access to these directories before the respective user logs in, would be a security issue.

Interestingly though if the home directory doesn't exist then GDM has absolutely no problem with it. So GDM does tolerate file does not exist, but doesn't tolerate permission denied.

So this makes me conclude that whatever GDM is trying to access from the home directories is not required at all.

So what is it that GDM is trying to get from the home directories? And more importantly, how can I disable it from trying to do so? How can I prevent it from hanging? Any ideas for some extra troubleshooting?

Or how can I make the mounted home directories invisible to GDM so that it won't trip over them?

Answer 1

Issue with /etc/gdm/*

In looking at the GNOME Display Manager Reference Manual I noticed several directories under /etc/gdm with different scripts and such.

There are a couple of references in these directories to $HOME. I'd try commenting those out to see if you can get rid of the access to $HOME.

To debug your issue further I'd be inclined to throw a couple of set -x lines at the top of the various scripts in these directories to see what's running prior to the "permissions denied" messages.

The script in the directories are all bash scripts on my systems.

/etc/gdm/custom.conf

debug option

There is a debug option in this file that is disabled by default. Try enabling it, the messages will show up in /var/log/messages.

[debug]
Enable=true

Disable faces in login

I'd also try disabling the inclusion of all user's faces at the gdm login in the face browser.

[greeter]
IncludeAll=false

Instead of disabling it you could experiment with disabling just one of your problem users by adding them to this list:

Exclude=<some user>

Update #1 - bugzilla issue

The issue appears to be related to this bug filed against the Red Hat Issue tracker, titled:

• Bug 908337 - GDM hangs with krb5 login and NFS4+krb5p home directory before asking for a password

There is no resolution but as part of the bug there was a test to confirm that you were experiencing this bug.

When the problem shows up GDM apparently creates a cache directory here: /var/run/user/42. Deleting this directory allows GDM login to proceed. The OP has confirmed this in the comments.

Update #2 - possible workarounds

There was a 2nd comment (by me) to some additional links with suggestions to work through the issue. The link titled:

• How to Mount Kerberized NFS Shares as a Member of the CSCF Active Directory

specifically in this section:

• Update The PAM Stack to Mount Personal NFS Disk Space At Logon

had some modifications to the PAM setup that might fix the issue.

Answer 2

One thing that gdm might look in home directories for is to get users' photos for displaying in the user list.

I think OpenSUSE uses gdm 3.6.2, is that correct?

Two things I suggest doing:

1. Enable debug logging as per gdm debugsection, try re-running gdm, and then see if there's anything useful in your system logs
2. Try disabling the user list as per Simple Greeter Configuration

Answer 3

It might be looking for .dmrc or something similar to load user session settings from. To make sure, attach to the gdm process with strace and check what files it is trying to open (and where it hangs). You probably want to use something like:

strace -f -o /path/to/logfile PID_OF_GDM

-f traces children processes as well, -o redirects log to a file (instaed of stderr).

If this is the case, putting the file into the user directory before it is mounted should fix the issue (but user won't be able to change it).

If it's not easily possible to attach to GDM before it crashes, you can edit the launcher (either the appropriate systemd unit or - if you are still sticking with sysvinit - the init script).

However, the safest way to catch it is to replace gdm with a wrapper script that would call the original binary (renamed to e.g. gdm.bin). Then no matter how the manager is spawned, it is going to be traced. You might also want to use a uniquely named file for output - just use $$ and/or `date --iso=ns` in the wrapper script:

#!/bin/bash
strace -f -o /path/to/gdm-${$}-$(date --iso-8601=ns).strace \
    /path/to/original/gdm.bin