Hi Steve, thanks for your input on this.
Steve Langasek wrote: > 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. b) and c) are indeed not taken care of. OTOH, it seems to me that the situation would get strictly better when the easy case is taken care of. > 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. While this is something to be concerned about, the forced restart is triggered by the local administrator in a situation where a good local administrator will advise the users to shut down applications and log out anyway. In my brief experiments, I was under the impression that inputs still are locked when a locking xscreensaver is killed. This needs verification, but if it is indeed the case the problem would be information disclosure. This seems not that different from allowing random screensavers when some of which do not conceal the content of the screen. Ideally, one would need to have a way to prevent this, though. > 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. OK, this is really what I wanted to know because, as you point out, implementing a forced restarting of xscreensaver takes some work, so if you as the maintainer prefer the status quo, I might as well pass. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
