Greg A. Woods writes:

[This is my final message on this issue, various possible solutions
have been proposed, also by you Greg, so I'm convinced the matter will
be resolved in some manner that is satisfactory to all.]

>That begs the (rhetorical) question -- why were you responsible for the
>outcome and why didn't the superuser take care of it?
[...]
>machine).  There is really no sane middle ground.  If you don't have
>complete physical access to the machine then you're not responsible for
>it and someone else should have the root password and they should manage
>the OS on it for you.

Greg, maybe you have once read RMS' ranting about why one should not
have security at all.  Although I strictly disagree with most of the
points he made, he was addressing one core problem (albeit by providing
the wrong solution, imho.)
In general, users sometimes have to fix certain problems immediately,
without assistance of the superuser.  In the case I was describing,
it was getting a workstation, i.e., a machine intended for single-user
work back to operating normally.
In particular, there were so many amok-running Netscapes and other
programs hogging the cpu and sitting on the swap, it was impossible
to get work done in any sane way.
The administrator was _not_ always reachable.  At times, these
things occurred after 5pm, when the sysadmin had already gone home,
or he was out of office occupied with something else, or on vacation.
Under the precondition that these machines were used kindof as
single-user workplaces anyways (there were no long-running user
processes which needed execution), the most straightforward way to
resolve the bad situation was simply to reboot the machine, exactly
like a PC that had gone instable.  This was a solution that took
only a couple of minutes, compared to hunting down the sysadmin
and getting him to kill off all the amok processes.
In addition, this situation occurred rather frequently, since for
some odd reason which I never could really identify, netscapes and
pines, elms, occasionally some other programs but mostly those
mentioned had a tendency to hang and use 100% cpu after the user
had logged out of X11 (seems to have something to do with them
not getting properly terminated before the user exited the window
manager.)
So there was always a good share of the machines which were virtually
unusable and computer pools were often crowded aswell.  Setting up
limits on a 32megs Alpha AXP machine with 64megs swap was not really
useful anyways.  Users which were logged in simply required all
memory and swap for doing larger operations.

>I.e. if a "public" workstation doesn't allow anyone to login as root on
>the "console" then it shouldn't allow a reboot from there either (at
>least not without an authorised user issuing the root password to 'su'
>or similar).

I prefer to sit at a workstation that works, instead of one that is
unusable but for which your (theoretically sensible) strict policy 
of "nothing and noone should reboot a Unix system but the superuser"
is applied.  If rebooting is a lot easier (means: a lot less time-
consuming) solution than alternatives, I will go for it.
There are real-life problems which occur and to which your idealistic
notions simply cannot (always) applied.  I personally care nothing
about uptime pride or whatever for single workplace machines.  I need
to be able to do my work, nothing else!

>We have that already in some sense.  It's (RLIMIT_NPROC * RLIMIT_DATA).

That's what I meant.  You get either very few processes or small
data limits.  In either way, it may be suitable for a timesharing
system, or a server, but not for a single workplace system, where
the user sitting at it should be able to fully use the machine
for his work.


>(i.e. this is not a valid excuse for wanting "ctrl+alt+del" support! :-)

I don't care that much anymore, the things I was talking about
happened mostly ca. 5-6 years ago.  They have replaced about all
Alphas with El-Cheapo Gnu/Linux PCs since, where the ctrl+alt+del
"feature" is available (I wouldn't care that much simply kicking
them in the nuts through powercycling anyways.)  The few alphas
that remain here are usually avoided by the large blob of users
who expose the "leave amok-running process turds behind" syndrome.
On the fast PCs with large memories it also doesn't matter that
much anymore.

--mkb