> Just as someone who has been bitten by this, I agree with James. The
> number one priority is keeping the machine up - I don't care what you
> kill, just keep it running and preferably allow remote logins still...
[SNIPPED]
> IMHO a completely seperate topic is how to prevent a malicious user from
> abusing this to nuke a machine.. That sounds like a very difficult prolem
> indeed.
There's already a 'user' structure haunting kernel sources. It'd be neat
if that was developed further so we could just limit all users to X megs
of VM, at least allowing us to forecast at what point the machine will
start to die, if nothing else.
Trying to impose acceptable limits right now is a bit.. well.. like trying
to operate a stealth bomber with oven mitts. You can have number of
process limits (with some exceptions, like cron). You can have max amount
of memory per process. But you can't just say "never let this user use
more than 50 megs of VM".
Trying to keep a user under 50 megs is tricky (DIFFICULT) with limits(5).
If you restrict them to 5 megs of VM per process, very few processes can
actually live past initialization. If you limit a user to less than 10
processes, a decent work environment becomes difficult (ie, user can't
even look up a man page while another process is suspended).
On a shell server, for example. The only solution here is to make the
limits(5) very high, disable cron (and other things that create user
presences outside of login), and sacrifice a few IDE drives to the machine
as lowest priority swap, so it's possible for root to log in and kill
offending processes (although it may take a couple of minutes)
I'm especially worried that this will never come about since you'd have to
keep track of resource allocation by uid in the kernel (or at least
offload it to userland), and that nobody would accept the speed hit, even
if it was entirely optional.
*sigh* :)
-MB
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:28 EST