Description of problem: 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. Version-Release number of selected component (if applicable): 2.13.5-1 How reproducible: Always Steps to Reproduce: 1. Get an AFS home directory 2. Lock your screen and wait for your tokens to expire (or use "sleep 30; unlog" to get rid of them) 3. Move the pointer or press a key on the keyboard Actual results: Nothing Expected results: The unlock dialog should appear Additional information: You may be able to simulate this case by adjusting the permissions of /home as root after the user locks the screen.
Created attachment 123396 [details] patch to fix the can't-chdir-to-homedir-so-I-give-up problem
Nalin, I think this is fixed in rawhide by a different patch to GNOME CVS. Can you verify?
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. Filed upstream as http://bugzilla.gnome.org/show_bug.cgi?id=331191
On rstrode's suggestion, I logged in using GDM instead of login + startx, to see if GDM would detect that $HOME was in AFS, and in response move the .Xauthority file to a local disk. No such luck: XAUTHORITY is still set to "/afs/devel.redhat.com/users/nalin/.Xauthority".
Not a blocker issue, since gdm can be configured to do the right thing, we don't support afs anyway (sorry, Nalin). At some point, we should probably look into making gdm do the right thing for afs out of the box.
For anyone who's reading this, a workaround for the can't-access-Xauthority problem: xhost +SI:localuser:$USER beforehand (thanks to Adam Jackson, who pointed this out elsewhere).
Add to FC6Destop tracker
So X should deny you access just because you go offline or your credentials fail. I've changed gdm's default configuration to put Xauthority in a local directory. That should fix this problem.
Hmm. I use "startx". Is there any chance that we can get the change from comment #7 made the default as well?