Bug 178233 - gnome-screensaver gets confused when access to $HOME disappears
gnome-screensaver gets confused when access to $HOME disappears
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnome-screensaver (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks: FC6Target FC6Desktop
  Show dependency treegraph
 
Reported: 2006-01-18 13:58 EST by Nalin Dahyabhai
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-21 15:28:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Nalin Dahyabhai 2006-01-18 13:58:56 EST
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 13:58:56 EST
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 16:37:52 EST
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 13:57:13 EST
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 15:38:48 EST
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-15 19:53:10 EST
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 13:26:56 EST
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 17:25:35 EST
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 17:49:52 EDT
Add to FC6Destop tracker
Comment 9 Ray Strode [halfline] 2006-07-21 15:28:32 EDT
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 15:33:46 EDT
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.