Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re:  locking screens and GrabServer and logging out users.
Message-ID: <9102071341.AA10865@lightning.McRCIM.McGill.EDU>
Date: 7 Feb 91 13:41:57 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 31

> 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