Date: Sat, 10 Apr 1999 14:08:41 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kevin Day <toasty@home.dragondata.com> Cc: hasty@rah.star-gate.com, dv@dv.ru, green@unixhelp.org, freebsd-current@FreeBSD.ORG Subject: Re: DoS from local users (fwd) Message-ID: <199904102108.OAA01678@apollo.backplane.com> References: <199904102057.PAA27724@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:On the shell servers I run, we've got 200-300 users running tasks.
:Occasionally, through intent or misconfiguration, a user either forkbombs,
:or gets a large number of processes running sucking lots of cpu.
:
:I'd like to see an option that makes all the processes run by one uid have
:the same weight as one process another uid is running.
:
:i.e. uid 1001 starts 40 processes eating as much cpu as they can. Then uid
:1002 starts up one process. Uid 1002's process gets 50% cpu, and uid 1001's
:40 processes get 50% cpu shared between them.
:
:This way, one errant user can't have as significant of an impact.
:
:Is this plausable?
:
:Kevin
Plausable, yes. Useful: probably not as useful as you might think. I
wouldn't even consider doing something like that for BEST, it could lead
to cascade failures.
For example, if a user is running procmail or cron on a relatively loaded
system, the user's share of the cpu relative to other users might not be
sufficient to handle the user's medium term mail and/or job load. If there
are a few hundred users logged in, this could rapidly devolve into a
cascade failure which fills the system's process table. This in turn can
lockup sendmail's waiting to lock the user's mailbox which in turn can
lead to a cascade failure with the root-run sendmails.
Sometimes, the most noble of purposes can make a machine less stable in
inobvious ways. In the above example, limitations on a user process might
lead to a backup of root-run services.
A user-run CGI is another example. Say you have a web server which runs
CGI's under a user id. If the web site is loaded down and the user happens
to run a log processing script, execs of the user's CGIs might slow down
due to the load balancing 'feature'. The web server may now wind up in the
situation where it is forking CGIs faster then it can retire them. Leading
to another cascade failure.
In general, it is best to treat process scheduling without taking into
account other processes run by the same user.
If a user misbehaves, the best solution is to stomp on him until he does
behave, not try to shove the misbehavior under the run by making the system
'control' the user's resources. If you do not actively control the
behavior of your users all you will accomplish is to have a large number of
them misbehaving continuously rather then just one or two. The result
is going to be the same: A loaded down server and lots of complaints.
users,
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904102108.OAA01678>