GNOME Bugzilla – Bug 331191
gnome-screensaver gets confused when access to $HOME disappears
Last modified: 2006-07-31 17:08:12 UTC
Originally filed here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178233 In environments where home directories are stored in AFS or NFS4 with RPCSEC_GSS in use, access to the home directory is denied unless the user has current, valid credentials. These credentials are time-limited, and once they expire, access is denied. This confuses gnome-screensaver in two ways. The first problem is that gnome-screensaver attempts to launch its helper applications with the user's home directory as the current directory. Because attempts to change to the directory are denied, the helpers never launch and the user is unable to unlock the screen. The second problem is that because the user's .Xauthority file can no longer be accessed, no helper which is launched is allowed to connect to the display. Using "xhost" to allow access to the display successfully works around this, but using xhost is frowned upon. [...] 2.13.90-2 can exec the dialog, but the dialog hits this error (extracted from a 100+MB strace file, which I'll attach if you like): 17426 access("/afs/devel.redhat.com/users/nalin/.Xauthority", R_OK) = -1 EACCES (Permission denied) 17426 writev(3, [{"l\0\v\0\0\0\0\0\0\0\0\0", 12}], 1) = 12 17426 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR) 17426 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0 17426 read(3, "\0\26\v\0\0\0\6\0", 8) = 8 17426 read(3, "No protocol specified\n\36\10", 24) = 24 17426 write(2, "Xlib: connection to \":0.0\" refused by server\r\nXlib: ", 52) = 52 17426 write(2, "No protocol specified\n", 22) = 22 17426 write(2, "\r\n", 2) = 2 17426 shutdown(3, 2 /* send and receive */) = 0 17426 close(3) = 0 17426 --- SIGSEGV (Segmentation fault) @ 0 (0) --- [...] A possible solution to this might be to start the lock dialog ahead of time, and only raise it when it is needed.
Right. The first problem should have been solved by: 2006-01-18 William Jon McCann <mccann@jhu.edu> * src/gs-window-x11.c (spawn_on_window): * src/gs-job.c (spawn_on_widget): Inherit cwd from parent. The second one is harder. I guess if there really is no way to automatically reauthorize accessing the home then the dialog needs to stay up. Unfortunately this means that it might have stale users/passwords etc cached if not using PAM.
Perhaps an .Xauthority can be stored locally and used via XAUTHORITY env var?
The only reasonable definition of "locally" here is $HOME, which is exactly the problem spot...
Why wouldn't a subdirectory of /tmp work?
The segfault should be fixed now in CVS. This was due to gtk_init_with_args not setting error when it failed. I've added a check for a NULL error.
nooo, don't put auth data in /tmp
I'm not going to do anything ;) Are you worried about someone deleting the auth data from /tmp/blah-username-XXXXX? Or something else? Isn't this what SSH does?
Looks like gdm uses /tmp too.
I'd like to explore the start-ahead-of-time option, because it would also help us with dialog startup time concerns (fear of glade, etc)
Fair enough. I'm just throwing it out there as an option. Still, seems a bit crazy to put the credentials necessary to access X on a filesystem that becomes inaccessible after a certain time and X is required to refresh the filesystem credentials.
So, I'm of the opinion that storing it in /tmp is probably the best way to go, too. The problem with starting it early is that if the lock dialog ever crashes for any reason, then there will be no way to start a new one on the display unless we have access to an authorized X authentication cookie.
Thinking out loud here... maybe then we can fix this in GDM. GDM could create a new xauthority file in /var/gdm whenever the $HOME is NFS or AFS and set the XAUTHORITY env var appropriately.
ok, so on my system (with nfs $HOME) gdm already sets XAUTHORITY to /tmp/.gdm<something> so, in all likeliness, the fix for this problem will be to make gdm treat AFS like NFS
Hi, The original reporter doesn't use gdm, so it may already do the right thing.
I'm going to mark this fixed since we fixed part of it here and deferring the rest to GDM. Please reopen if we need to readdress this in the future.
*** Bug 349398 has been marked as a duplicate of this bug. ***