Zapping the Xorg server

[Eirik Byrkjeflot Anonsen]

Peter Hutterer <peter.hutterer at who-t.net> writes:

> On Thu, Aug 26, 2010 at 02:45:51AM +0200, Wolfgang Draxinger wrote:
[...]
>> I this particular case: I'm system administrator at my university's
>> student computer lab. Some students tend to lock their sessions,
>> (override-)configuring {x,gnome,k}screensaver not to allow opening a
>> new session AND in the background start lengthy computational jobs.
>> 
>> This is strictly disallowed by us. We got a job queue engine for that.
>> 
>> People are explicitly allowed to "zap" locked sessions, if it's
>> obvious, the user who used the machine last went for lunch or came in
>> in the morning, starting his job, coming back sometime in the evening.
>> Or people just forget to log out.
>> 
>> But it's the hogs I'm worried about. And since you can disable the Xkb
>> option for terminate, I'm pretty sure, those would eventually find it.
>> 
>> Allowing ordinary users to "zap" is allowed for two reasons: There's not
>> always an operator on shift who could sudo-pkill the session, and it's
>> also meant as some sort of education: "Don't be a hog, and don't leave
>> your station with unsaved data."
>  
> if you rely on users to zap the session for CPU hogs, then I think the real
> problem is elsewhere, but not in whether the user can change the XKB map or
> not.

In general I agree, but I can see how it can be a useful and educational
strategy in this case.  I might argue that there are better ways, but I
won't argue that this choice is unreasonable.

Of course, that implies that Wolfgang's case is truly a special case and
should not dictate general X behaviour.  Probably the correct solution
to support this behaviour is that the university should use its own
version of the keyboard driver (evdev, I assume), which recognizes
ctl+alt+backspace and zaps the server.

eirik