Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!novavax!twwells!bill
From: bill@twwells.uucp (T. William Wells)
Newsgroups: comp.bugs.sys5
Subject: Re: ulimit (was: getty/login for callback)
Message-ID: <836@twwells.uucp>
Date: 21 Apr 89 04:10:37 GMT
References: <180001@mechp10.UUCP> <13853@rpp386.Dallas.TX.US> <797@twwells.uucp> <827@twwells.uucp> <120@mslanpar>
Reply-To: bill@twwells.UUCP (T. William Wells)
Organization: None, Ft. Lauderdale
Lines: 58
Summary:
Expires:
Sender:
Followup-To:
Distribution:
Keywords:

In article <120@mslanpar> pat@mslanpar (Pat "King of the Trenches" Calhoun) writes:
: In article <827@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes:
: > This is what I heard, also. But it fails to explain why increasing
: > ones ulimit is restricted to root. If ulimit is only a safety belt,
: > there isn't any good reason for preventing one from tightening or
: > loosening it as needed.
: >
:
:       WARNING: NO SPACE ON DISK 0 PARTITION 0!!! :=)
:
:       In most states, safety belts are not an option. With this in
:       mind, it would be useless to have a safety device that could
:       be overridden by anyone. This defeats the purpose of having
:       a ulimit.

Really? I know of few safety devices that can't be overridden by
their users. And I hardly find safety belts to be useless just because
some users can choose to not put them on.

So much for that speciousness.

:                  The message above is not a fantasy, but reality,
:       and when it does occur, it's usually a pain to clear out the
:       files (making sure not to get rid of anything of value!)

A better analogy than a seat belt would be a glare protector that
prevents you from seeing out half the front wiindow. :-)

However, the point is this: if you want to run a shop where the user
is presumed to be stupid or malicious till proven otherwise, you
might want to hedge him round with all kinds of restrictions. You
might, in such a case, be able to argue that making ulimit restricted
to superuser is a good idea; I'd argue that giving users access to the
shell in such a circumstance merely demonstrates the stupidity of the
system administrator. Under those circumstances, you don't let the
users run shells, you let them run applications only. And those
applications should have whatever restrictions you need built in.

You might argue that, e.g., in a university environment, you have
users who might be stupid or malicious, who you need to give a shell
to, and you need ulimit to keep them in line. My response would be:
bull. Having ulimit be privileged won't do squat to protect you from
such users. You need quotas. And on more than just disk space.

If, on the other hand, you are running a system where people are
doing work that requires a shell, you'd *better* have users who can
make informed decisions on when to set ulimit up or down. And in that
case, you don't want ulimit privileged.

In short, having ulimit be privileged fails to prevent the stupid or
malicious from buggering your system and may prevent the competent
from doing their job. Thus ulimit shouldn't be privileged.

---
Bill                            { uunet | novavax } !twwells!bill
(BTW, I'm may be looking for a new job sometime in the next few
months.  If you know of a good one where I can be based in South
Florida do send me e-mail.)