On Wed, Oct 22, 2008 at 08:49:27AM +0200, Thomas Viehmann wrote: > probably I'm just dense, but why would (the admittedly gross hack) of > looking at /proc/$XSCREENSAVER-PID/environ (for DISPLAY and XAUTHORITY), > getting uid for that process, trying xscreensaver-command -exit, if the > screensaver exited, start xscreensaver again with that uid and environ, > otherwise (it will have been locked) killing the xscreensaver, starting > xscreensaver, doing xscreensaver-command -lock not do the trick better > than the current state?
Well, that sounds better than the current state, but a) the code for it isn't written and I'm not familiar enough with xscreensaver to be confident of getting it right on the first try myself, b) we have to cover more than just xscreensaver (xlockmore is also affected AIUI), c) I'm not sure if peeking in /proc is going to work if the user has SELinux turned on. It also seems to introduce a race condition where the display is unlocked and vulnerable to attack during the upgrade, which I'd prefer not to have pam itself be responsible for. I think advising the user to disable the screensaver for the duration of the upgrade is a choice I'd be more comfortable with, rather than forcibly restarting the screensaver. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
