Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 178233 - gnome-screensaver gets confused when access to $HOME disappears
Summary: gnome-screensaver gets confused when access to $HOME disappears
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-screensaver
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC6Target FC6Desktop
TreeView+ depends on / blocked
 
Reported: 2006-01-18 18:58 UTC by Nalin Dahyabhai
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-07-21 19:28:32 UTC


Attachments (Terms of Use)
patch to fix the can't-chdir-to-homedir-so-I-give-up problem (deleted)
2006-01-18 18:58 UTC, Nalin Dahyabhai
no flags Details | Diff

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?


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