jam> I wouldn't want *any* way to change this at run-time-- once someone has
jam> 'root' acceess to the machine, they can circumvent whatever they want.
jam>
jam> what kind of environment are you describing?
Think of a High School or University lab full of computers, or something
like a public library terminal. The physical computers are locked in a
cabinet with only the keyboard/mouse and monitor protruding, so the user
cannot reset the machine or pull the power cord. The user does not have
root access. (console access != root access). A simple sysctl/proc entry
to enable/disable sysrq would be _very_ useful in this case.
(the lab administrator could keep it disabled by default, but enable it
when he's trying out a new kernel/installing a new X server/anythign that
could put the computer in a position where he might want to use sysrq, by
echo'ing 1 to the appropriate file in /proc, then disable it again after
he's finished by echo'ing a 0)
My personal, private opinion is that sysrq should be configurable in
config/menuconfig like it is now, defaulting to off, but requiring root to
ALSO echo a 1 to a value in /proc to turn it on. (something along the
lines of what you have to do to enable ip_forward etc)
Note that I personally don't NEED this option since nobody has physical
access to my production servers, so I'd probably leave it enabled all the
time anyway, but I can easily see where having it run-time configurable
can be very useful for many people.
- Matt Kemner
System Administrator
Networx Internet
Western Australia
++61 8 9345 3377
P.S. For those of you that are considering replying with "but what about
control-alt-delete", check out the "ca" entry in your inittab, and make it
run something other than shutdown.
(eg ca:12345:ctrlaltdel:/bin/echo "I don't think so, Tim.")
P.P.S I would code up a patch for this myself, but you _really_ don't want
to see my C coding :P
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu