After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331191 - gnome-screensaver gets confused when access to $HOME disappears
gnome-screensaver gets confused when access to $HOME disappears
Status: RESOLVED FIXED
Product: gnome-screensaver
Classification: Deprecated
Component: dialog
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-screensaver maintainers
gnome-screensaver maintainers
: 349398 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-02-14 20:43 UTC by Matthias Clasen
Modified: 2006-07-31 17:08 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matthias Clasen 2006-02-14 20:43:29 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.
Comment 1 William Jon McCann 2006-02-14 20:49:36 UTC
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.
Comment 2 William Jon McCann 2006-02-14 20:55:42 UTC
Perhaps an .Xauthority can be stored locally and used via XAUTHORITY env var?
Comment 3 Matthias Clasen 2006-02-14 21:04:12 UTC
The only reasonable definition of "locally" here is $HOME, which is exactly 
the problem spot...
Comment 4 William Jon McCann 2006-02-14 21:07:21 UTC
Why wouldn't a subdirectory of /tmp work?
Comment 5 William Jon McCann 2006-02-14 21:15:23 UTC
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.
Comment 6 Matthias Clasen 2006-02-14 21:20:30 UTC
nooo, don't put auth data in /tmp
Comment 7 William Jon McCann 2006-02-14 21:26:40 UTC
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?
Comment 8 William Jon McCann 2006-02-14 21:57:57 UTC
Looks like gdm uses /tmp too.
Comment 9 Matthias Clasen 2006-02-15 05:13:57 UTC
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)
Comment 10 William Jon McCann 2006-02-15 17:05:46 UTC
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.
Comment 11 Ray Strode [halfline] 2006-02-15 19:24:10 UTC
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.
Comment 12 William Jon McCann 2006-02-15 19:34:04 UTC
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.
Comment 13 Matthias Clasen 2006-02-15 19:49:28 UTC
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
Comment 14 Ray Strode [halfline] 2006-02-15 21:41:14 UTC
Hi,

The original reporter doesn't use gdm, so it may already do the right thing.
Comment 15 William Jon McCann 2006-03-31 18:05:48 UTC
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.
Comment 16 William Jon McCann 2006-07-31 17:08:12 UTC
*** Bug 349398 has been marked as a duplicate of this bug. ***