🚀 go-pugleaf

In article <rik.716283238@nella13.cc.monash.edu.au> rik.harris@fcit.monash.edu.au writes:
>>Simple policy fix: ``If the terminal is locked with anything other than
>>the "standard" lockscreen, it may be rebooted in order to clear the
>>lock.''

Nobody I know reboots terminals - I assume this means "computer" :)

>There's a similar discussion going on at Monash.  Unfortunately the same
>``solution'' came up here.  The problem with Christopher's method is
>that the person who ran the non-standard lockscreen doesn't lose
>by this (any more than a ``log out after 15 mins'' approach), but the
>people who are remotely logged in do lose.  You are punishing the
>remote users, just because of one idiot locking the screen the
>``wrong'' way.

If you have the right set of circumstances, you can just tell people how 
to defeat the lock program.  I just got some HP 9000/710 so I'll use it
as an example:

Normally, you walk up to the machine and see an X based login.  Suppose
you see xlock instead.  You type CTRL-SHIFT-BREAK and the X server dies.
After a few seconds, its back with a new login screen.  Your file
system doesn't get trashed (if you use local disks) and remote users don't
get dropped.

The last time I had a computer with X on it was back when it was R2, and
I can't remember if all the servers had a kill feature like this, but if you
have it, the whole lockscreen thing is a non-issue.  The lockscreen program
prevents unauthorized access to your account while you are away, but does
not allow denial of service.

Mark S.