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. Could probably hack
gnome-screensaver to pass the magic cookie, etc. to the dialog process to
avoid it requiring access to ~/.Xauthority, but I doubt gnome-screensaver
maintainers would be interested in supporting that sort of change for a
small user base of AFS users.
We ended up replacing gnome-screensaver with xautolock+xlockmore combination.
(xlockmore does not use a separate process for the dialog screen. To maintain
reasonable security, it does not offer all the flexibility, etc. in the dialog
screen that gnome-screensaver does). (We still allow users to use
gnome-screensaver if they really want to, but with caveat is unsupported and
in particular can be problematic if leave screen locked overnight).
Hi,
We are also using Ubuntu 10.04 paired with AFS home dirs and I am facing
a hard problem with Gnome. Opening and closing sessions work flawlessly,
but when users lock their workstation at night, they can't unlock it the
following morning. Of course their TGT and AFS tokens expire overnight,
which is the main cause of the problem. I read in the discussion that a
GCONF_LOCAL_LOCKS variable might exist, which sounded promising but has
no effect nowadays. The problem only occurs with Gnome, KDE is fine. I
spend many ours trying to debug this issue.
The issue is reproductible for me using this approach:
running gnome-screensaver in debug
renew TGT with 10 seconds lifetime and lock
wait 15 minutes -> the GUI is freezed
killing in console gives back the GUI and I can renew TGT in a terminal
ex:
cd /tmp
apt-get source gnome-screensaver
cd gnome-screensaver-xxx/src/
sh debug-screensaver.sh (can be tuned to send log to /tmp/xxx.log)
kinit -l 10 [email protected]
Any of you could point me in a direction on how to solve this ? I might
end up using xlock or xscreensaver, but I'd prefer to stay close to the
"default" environement.
Regards,
Thomas.
On Fri, Dec 10, 2010 at 1:54 PM, Thomas Briggs <[email protected]>
wrote:
We use a mixed environment of Ubuntu 10.04 and Mac OSX
machines in our labs and classrooms. After our upgrade to
Ubuntu 10.04, are users are noticing that the first time they
log in, GDM accepts their password, starts a session, and
then terminates. They can usually log in the second time,
though sometimes it takes two or three tries. After a few
days of running, a 'ps -eaf' shows stray processes from just
about every user, and every login session since the last
reboot.
Why am I asking here? Because this doesn't seem to be
widespread Ubuntu problem, and I suspect it has something to
do with the interaction between some new aberration of nature
in Ubuntu 10.04 (and there are many) and the user's home
directories, which are on AFS, and hopefully there is another
school using it for their classrooms like we. Also, people
on this group seem to be more helpful, patient, intelligent,
and just downright better people :-)
-tom
-------------------------------------------
Dr. Thomas Briggs, Assoc. Professor
Dept. of Computer Science, Shippensburg University
1871 Old Main Drive / Shippensburg, PA 17257 / (717) 477-1178
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
Tom Payerle
OIT-TSS-DCS [email protected]
University of Maryland (301) 405-6135
College Park, MD 20742-4111
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
