On Sat, Nov 15, 2008 at 11:55:55PM -0800, Steve Langasek wrote:
> 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.
I've filed a bug against release-notes which such an advise (bug number
not yet available).
| During the upgrade of the Pluggable Authentication Modules system, the
| authentication modes need to be restarted. Some services used for locking
| a user session cannot be restarted, e.g. xscreensaver, gnome-screensaver
| or xlockmore. It is recommended to stop them before starting the update.
So we can downgrade this to something not-RC.
Cheers,
Moritz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
