naughton@wind.Eng.Sun.COM (Patrick Naughton) (02/06/91)
There have been a few questions posted about lockscreen programs which
all have the same answer.
One X user wants the "lockscreen -e" option from SunView so that a
person can "log out" the current X server user when the screen is
locked.
Another guy wonders about the effects of nlock's use of XGrabServer()
on the event queue's and "unlock time lag" where your xclock spins it's
hands like mad for a few hours if you unlock a server after it has been
locked for a long time. Or even worse if you have a GrabServer in
effect, all of the queue's on the client side keep getting larger and
larger possibly exhausting the swap on the client machines and crashing
the clients and/or the server.
The author of nlock defends his choice based on security vis a vis the
possibility of a terminal being raised above the lockscreen's window
for an instant, long enough for the user to type "^C". Aside from the
fact that if you have the Keyboard and Mouse grabbed this can't happen,
it is true that xlock will allow you to "see" a window that has been
raised for a few moments before the VisibilityNotify event tells xlock
to hide it again. I think I chose the lesser of two evils.
The solution to all of these problems is that screen locking should be
a function of the window manager, not an external client. The window
manager can ignore all map requests while the screen is locked and it
can kill all of the active programs and end the session if it so
desires... I see no clean, ICCCM compliant, way of doing either of
these from xlock, but it should be straightforward to do it in *wm.
-Patrick
--
______________________________________________________________________
Patrick J. Naughton ARPA: naughton@sun.com
Sun Microsystems, Inc. AT&T: (415) 336 - 1080mouse@lightning.mcrcim.mcgill.EDU (02/07/91)
> There have been a few questions posted about lockscreen programs > which all have the same answer. [...] I mostly agree, but have a couple of quibbles: > The author of nlock defends his choice [to use XGrabServer] based on > security vis a vis the possibility of a terminal being raised above > the lockscreen's window for an instant, long enough for the user to > type "^C". Aside from the fact that if you have the Keyboard and > Mouse grabbed this can't happen, Well, it can happen, but if the keyboard is grabbed by the screen locker the user can't type the ^C into the "other" window regardless of how long it's there. > The solution to all of these problems is that screen locking should > be a function of the window manager, not an external client. The > window manager can ignore all map requests while the screen is locked > and it can kill all of the active programs and end the session if it > so desires... The window manager may not be able to end the session. The xinit distinguished client (or .xsession distinguished client, or whatever) may not only not be the window manager, it may not be possible for the window manager to detect its existence, never mind kill it. (XKillClient works only on clients that create resources.) der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu