On 12/22/2010 2:35 PM, Thomas M. Payerle wrote: > On Wed, 22 Dec 2010, Thomas Calderon wrote: > > We encountered the same issue when rolling out an updated desktop > environment using Gnome. > > gnome-screensaver, for various security reasons, takes a multiprocess > approach. The main locking process detects mouse/keyboard activity, and > then runs another process to handle the dialog (this allows the dialog > process > to safely use higher level desktop widgets, themes, etc. If it crashes, > the > screen remains locked, which is the secure alternative.) > > The issue occurs if home directories are in AFS, and the AFS tokens expire > between the locking of the screen and when attempt to unlock it. The > dialog > process then tries to open a window on the display to prompt for the > password, > but cannot access ~/.Xauthority as it is in the AFS located home directory > and does not have valid AFS tokens. > > I do not see any good ways to get around this. Allowing something w/out > user's tokens read access to ~/.Xauthority seems rather questionable, > plus awkward as needs some access to ~ as well.
Perhaps at logon the machine is added as an IP ACL to the requisite directory using the user's acquired token and then removing the ACL at logout. (or something along that line of thought....) Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
