GNOME Bugzilla – Bug 349398
gnome-screensaver can't spawn child processes when afs tokens run out
Last modified: 2006-08-02 13:43:03 UTC
Please describe the problem: When running gnome with an AFS home directory gnome screensaver-dialog won't run if the users afs token runs out. Recovering the windows session requires having to log in remotely or vial a virtual console, gaining new afs tokens and killing gnome-screensaver which is messy. Steps to reproduce: 1. You need an account with an afs homedir 2. Set the screensaver idle timeout to something short 3. wait for the screensaver to kick in 4. log in remotely and expire the afs token using unlog 5. go back to your original gnome login and try to login Actual results: the gnome-login dialog won't appear as expected. Expected results: the gnome-dialog box should appear and allow the user to authenticate Does this happen every time? yes. Other information: This seems to be happening because gnome-screensavers child processes can't access ~/.Xauthority. Is there any way to securely hand the magic-cookie to screensaver-dialog, either by some inter process communication or by stashing it somewhere on the local disk?
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. Do you use gdm? *** This bug has been marked as a duplicate of 331191 ***
Yes we're using gdm and as per the other bug it's stashing the auth data in /tmp/.gdmXXXXX when it detects an NFS homedirectory, it's not doing that for AFS I'll check with the gdm folk. NB A temporary fix is to set UserAuthDir=/tmp in /etc/X11/gdm/gdm.conf (or the equivalent file for your distro) which will force gdm to stash xauth info there. thanks for pointing me at the solution.