Greg A. Woods writes:

>> However, allowing them to safely reboot a workstation (i.e., without
>> just hitting the switch, which would happen otherwise, no matter

>NetBSD doesn't get in that state very often, at least not in releases
>which are what should be running on public computer pools!  Not only
>that, but if it does then the reset switch might be necessary anyway.

I just want to provide two real-life examples I have personally
encountered in the past several times;

First, there's the problem of administrator not being reachable
and the workstation is question is hogged by several amok-running
netscapes, pines etc. (which seems to happen surprisingly often,
on various systems, although I personally have never been able to
reproduce it.)  In my case, this was very annoying, since it was
on small (and slow) Alphas, with rather limited memory and it was
a serious obstacle to getting work done since not only was the CPU
busy but also swap was almost filled by the swapped out pages.
Since DEC Unix doesn't have something like the Vulcan Nerve Pinch,
what I did was simply run "sync" in a "for" loop for a couple of
seconds and then hit the switch.  Ugly but works most of the time
(one time it didn't, tho, had to fsck manually then.)  Admittedly,
this probably isn't that much of a problem these days, with fast
CPUs and large memory/swap configurations but still.

The second problem is with intended malicious user actions, like
my favourite example of "while :; do grep asdf /dev/zero&; done"
which usually locks up solid systems like *BSD and Gnu/Linux
(especially when they're using Gnu grep, which attempts to suck in
a whole line into memory.)  Users just do such things eventually,
I know it from first hand experience[1], and you cannot really
prevent this with user limits.  This might of course also result
from an unintended situation, simply when the user is doing something
stupid.  You do not want to powercycle the machine in such a case
either, since you risk damage to the filesystems.  An easy method
for safely rebooting the workstation without superuser privileges
is useful here aswell.  I don't think I have to mention that allowing
the user to drop into the kernel debugger is prohibitive here, from
a security POV.

--mkb

<offtopic>
[1] the "victim" in that case really deserved it, though, and we
always had big fun watching, since first he was quite a loudmouthed,
unsympathetic type of person, bragging about with his "superior
computer knowledge" and was completely hyperventilating and going
wild, when the machine went into a state that he could not resolve
by applying his "superior knowledge", especially when previously
large-eyed girls where breaking into a big grin at that and he made
a real monkey out of himself cursing and hitting the poor box... :)
</offtopic>