Bug 178233

Summary: gnome-screensaver gets confused when access to $HOME disappears
Product: [Fedora] Fedora Reporter: Nalin Dahyabhai <nalin>
Component: gnome-screensaverAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jmccann
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-21 19:28:32 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 150223, 197822    
Attachments:
Description Flags
patch to fix the can't-chdir-to-homedir-so-I-give-up problem none

Description Nalin Dahyabhai 2006-01-18 18:58:56 UTC 
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.
Comment 1 Nalin Dahyabhai 2006-01-18 18:58:56 UTC 
Created attachment 123396 [details]
patch to fix the can't-chdir-to-homedir-so-I-give-up problem
Comment 2 Christopher Aillon 2006-02-07 21:37:52 UTC 
Nalin, I think this is fixed in rawhide by a different patch to GNOME CVS.  Can
you verify?
Comment 3 Nalin Dahyabhai 2006-02-08 18:57:13 UTC 
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) ---
Comment 4 Matthias Clasen 2006-02-14 20:38:48 UTC 
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
Comment 5 Nalin Dahyabhai 2006-02-16 00:53:10 UTC 
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".
Comment 6 Matthias Clasen 2006-02-21 18:26:56 UTC 
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.
Comment 7 Nalin Dahyabhai 2006-03-10 22:25:35 UTC 
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).
Comment 8 Matthias Clasen 2006-07-06 21:49:52 UTC 
Add to FC6Destop tracker
Comment 9 Ray Strode [halfline] 2006-07-21 19:28:32 UTC 
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.
Comment 10 Nalin Dahyabhai 2006-07-21 19:33:46 UTC 
Hmm.  I use "startx".  Is there any chance that we can get the change from
comment #7 made the default as well?