n userspace.
(the BSD's set the limit lower in kernel and let users who need more
raise with userland tools)
I wouldn't bother if this wouldn't give Linux a bad reputation.
I'm Sorry if I made some people upset.
--
Natanael Copa
-
To unsubscribe from this list: send the line
like max_threads (in case
you try run Linux on 2MiB RAM)
If a fixed value (like 300, 512, 2000) is used then will probably
systems with low amount of RAM be vulerable to the forkbomb attack.
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
he default max_threads and RLIMIT_NPROC to half of the current
default)
and my system survived.
[EMAIL PROTECTED] ~ $ ulimit -u
4093
(I have 1 GiB RAM)
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
imits.conf does not.
If it does cause problems for extrem users, they can easily raise the
limits in either initrd and/or using /proc/sys/kernel/threads-max (or
systctl).
BTW... does anyone know *why* the default max number of processes is so
high in Linux?
--
Natanael Copa
-
To unsubscribe fro
n not raise the limit,
just lower it. So unless limits are set in the bootscripts, the defaults
set in kernel/fork.c will be used on services.
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTE
limited
in /etc/security/limits.conf it will be able to fork many more
processes.
> > It should exist a global limit in case someone could spawn
> > a shell without limits through some flawed application.
I agree on this one. Or the RLIMIT_NPROC should be set to a lower value
by de
ubt that. Try raising your maxproc setting (sysctl
kern.maxproc?) to something insane and try bombing again.
I tried to bring the box down by raising the limit to something similar
linux default and run the classic ":() { :|:& };:" However, the bomb was
stopped by maximum number of pipes
lly, Alan Cox tried this in the 2.4.7-ac1 kernel
http://marc.theaimsgroup.com/?l=linux-kernel&m=99617009115570&w=2
but I have no idea why it was raised to the double afterwards.
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
e kernel, the existing one works fine for most purposes, when
> combined with appropriate administrative tools.
My point is, the default max allowed processes per user is too high. It
better to open up a restrictive default than locking down an generous
default.
--
Natanael Copa
-
To unsubs
/security/limits.conf) Mail notification died because it
couldn't start any new threads but that was the only thing that
happened.
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2005-03-23 at 15:52 +0100, Max Kellermann wrote:
> You see, RLIMIT_CPU is worthless in its current implementation.
You are right. Limiting CPU is probably not a good solution anyway.
http://marc.theaimsgroup.com/?l=linux-kernel&m=105808941823955&w=2
--
Natanael Copa
-
To
On Wed, 2005-03-23 at 15:43 +0100, Jan Engelhardt wrote:
> >brings down almost all linux distro's while other *nixes survives.
>
> Let's see if this can be confirmed.
open/free/netbsd survives. I guess OSX does too.
Gentoo (non-hardened), Red Hat, Mandrake, FC2 are vulnerable.
Debian stable sur
On Wed, 2005-03-23 at 15:27 +0100, Max Kellermann wrote:
> On 2005/03/23 15:23, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > On Wed, 2005-03-23 at 14:53 +0100, Max Kellermann wrote:
> > > The number of processes is counted per user, but CPU time and memory
> > > c
es is counted per user, but CPU time and memory
> consumption is counted per process.
So limiting maximum number of processes will automatically limit CPU
time and memory consumption per user?
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel&
On Wed, 2005-03-23 at 14:45 +0100, Erik Mouw wrote:
> On Wed, Mar 23, 2005 at 01:37:38PM +0100, Natanael Copa wrote:
> > On Wed, 2005-03-23 at 19:56 +0900, aq wrote:
> > > > /etc/limits does a better job at stopping forkbombs.
> >
> > but does not limit process
On Wed, 2005-03-23 at 22:04 +0900, aq wrote:
> On Wed, 23 Mar 2005 13:37:38 +0100, Natanael Copa <[EMAIL PROTECTED]> wrote:
> > > > This is an example of a program in C my friends gave me that forkbombs.
> > > > My previous sysctl.conf hack can't stop this,
fork.c 2005-03-21 15:22:50.0 +0100
@@ -119,7 +119,7 @@
* value: the thread structures can take up at most half
* of memory.
*/
- max_threads = mempages / (8 * THREAD_SIZE / PAGE_SIZE);
+ max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
uld it be an idea to set it back to:
mempages / (16 * THREAD_SIZE / PAGE_SIZE)
and let the sysadmins raise the limit with /proc/sys/kernel/threads-max
if they need more?
--
Natanael Copa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
18 matches
Mail list logo
