On Sun, 17 Feb 2002, Peter Wemm wrote:
> No. Root's overrides come *after* automagic settings, regardless of how
> well intentioned the settings are.
>
> If you are going to do this, it should be something along the lines of:
> maxproc = NPROC;
> if (maxproc > automaxproc)
>
Mike Silbersack wrote:
> 2. Limit the number of procs to an appropriate number. Previously, it
> was easy to set maxproc overly high by setting a large maxusers value.
> With this change, proc-related structures will only be able to consume
> about 1/2 of all system memory. Without this limita
change #3, as it ensures
that less processor time will be wasted by continuous fork()ing.
There are certainly a few remaining issues with more complex resource
exhaustion attacks, but that can be dealt with in future patches.
If you were interested in the fork rate limit thread, please give this
pat
Hello!
i was not intended to include following lines to the patch:
--
@@ -36,7 +36,7 @@
* SUCH DAMAGE.
*
*@(#)kern_fork.c8.6 (Berkeley) 4/8/94
- * $FreeBSD: src/sys/kern/kern_fork.c,v 1.130 2002/02/07 23:06:26 peter Exp $
+ * $FreeBSD: src/sys/kern/kern_fork.c,v 1.128 2002/01/13 11:57:59 a
sses spawn
> in which period. The only place from where you can set limits is a
> login.conf. Also fork rate-limit does not affect processes which belong
> to root.
I finished looking at the patch, and I'm not impressed by it. It looks
like the patch I'm working on will work mo
sses spawn
> in which period. The only place from where you can set limits is a
> login.conf. Also fork rate-limit does not affect processes which belong
> to root.
>
> Patch is created against 10 Feb 20:00 UTC sources.
> copy it to /usr/src and run 'patch -p1 < diffi'
&
login.conf. Also fork rate-limit does not affect processes which belong
to root.
Patch is created against 10 Feb 20:00 UTC sources.
copy it to /usr/src and run 'patch -p1 < diffi'
--
Gaspar Chilingarov
diff -r -u /usr/src/lib/libc/sys/getrlimit.2 src/lib/libc/sys/getrlimit.2
--
First of all, thanks to all for telling their opinions :)
I prefer to enforce both some preventive software measures as well
administrative ones. But i do not what that some
kiddie/newbie/clueless one to take down box that is shared among
many other students a
good point. it seems that on open (yet restricted) systems, users wouldn't
be ./configure'ing much software, particularly if quotas are small and
network access is next to none, which would leave me inclined to go with
the kill().
But, of course, that would just be for my own uses. Perhaps ther
In the last episode (Feb 04), Anthony Schneider said:
> I've actually wanted something like this for a while and have considered
> coding it myself. Perhaps this could go into a login.conf variable
> (which I would have to create myself), but originally my plan was basically
> kill off parent pro
I've actually wanted something like this for a while and have considered
coding it myself. Perhaps this could go into a login.conf variable
(which I would have to create myself), but originally my plan was basically
kill off parent processes with the uid of the user who is fork()'ing too
often (2
On Sun, 3 Feb 2002 18:02:13 -0500
Mike Barcroft <[EMAIL PROTECTED]> wrote:
> He should be able to pick his own administrative policy.
And what I pointed out was simply another choice. Whether he implements
the solution in software or takes the administrative route is obviously
his choice. And if
On Sun, 3 Feb 2002, Robert Watson wrote:
> BTW, many sites find the per-uid process limits helpful in preventing fork
> bombs from crippling the site. The default configuration may not be
> sufficiently agressive, and while it's not the same as a rate limit, it
> does have the effect of topping
On Sun, 3 Feb 2002, Mike Barcroft wrote:
> > This means less work for you, and no need to continuously maintain diffs
> > against the kernel sources. IMO it's a *very,very* bad thing to
> > introduce changes into the kernel that might introduce unintended side
> > effects when the problem can be
Mike Makonnen <[EMAIL PROTECTED]> writes:
> On Sun, 3 Feb 2002 02:35:46 +0400
> Gaspar Chilingarov <[EMAIL PROTECTED]> wrote:
>
> > I've got such situation on our free shellbox set up in the
> > university - some newbies were kidding with old while(1) fork();
> >
On Sun, 3 Feb 2002 02:35:46 +0400
Gaspar Chilingarov <[EMAIL PROTECTED]> wrote:
> I've got such situation on our free shellbox set up in the
> university - some newbies were kidding with old while(1) fork();
> attack. Finnaly they got hit by memory limits
-> Date: Sat, 2 Feb 2002 12:52:24 -0800 (PST)
-> From: Matthew Dillon <[EMAIL PROTECTED]>
-> To: Gaspar Chilingarov <[EMAIL PROTECTED]>
-> Cc: [EMAIL PROTECTED]
-> Subject: Re: fork rate limit
->
-> :Hi!
-> :
-> :Is it reasonable to administratively li
:Hi!
:
:Is it reasonable to administratively limit users' ability to call fork
:too other ? Users can take away too much CPU time even if you have
:limited them by login.conf 'cputime' limit - just forking lightweight
:processes too often.
:
:If it seems good thing to do, i'll try to code it and s
Hi!
Is it reasonable to administratively limit users' ability to call fork
too other ? Users can take away too much CPU time even if you have
limited them by login.conf 'cputime' limit - just forking lightweight
processes too often.
If it seems good thing to do, i'll try to code it and submit pa
19 matches
Mail list logo
