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 "unsubscribe linux-kernel" in
the body of a m
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 unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
hreads (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
the bod
(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
the body of a message to [EMAIL PROTECTED]
More majordomo info at http
_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/
the patch mentioned here:
http://marc.theaimsgroup.com/?l=linux-kernelm=111209980932023w=2
(it set the 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
.
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 from this list: send th
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 from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
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 PROTECTED]
Mo
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 PROTECTED]
More majordomo info at http://vger.kernel.org
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
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 an
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 default.
--
Natanael Copa
-
To unsubscribe from this list: send the line
lly, Alan Cox tried this in the 2.4.7-ac1 kernel
http://marc.theaimsgroup.com/?l=linux-kernel=99617009115570=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 body of a mess
xisting 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 unsubscribe from this
/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=105808941823955=2
--
Natanael Copa
-
To unsubscribe f
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
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
ocesses 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, but
000 +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);
/*
* we need to allow at l
);
+ max_threads = mempages / (16 * THREAD_SIZE / PAGE_SIZE);
/*
* we need to allow at least 20 threads to boot a system
--
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
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, but the /etc/limits
solution
enables
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 processes that are started from the boot scripts. So
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 in
the body of a message to [EMAIL PROTECTED]
More
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
consumption is counted per process.
So
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
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-kernelm=105808941823955w=2
--
Natanael Copa
-
To unsubscribe
); } }
Interesting.
With the patch I suggested earlier, reducing default max_threads to the
half in kernel/fork.c, my system survived. (without
touching /etc/security/limits.conf) Mail notification died because it
couldn't start any new threads but that was the only thing that
happened.
--
Natanael Copa
allowed processes per user is too high. It
better to open up a restrictive default than locking down an generous
default.
--
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
, Alan Cox tried this in the 2.4.7-ac1 kernel
http://marc.theaimsgroup.com/?l=linux-kernelm=99617009115570w=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 body of a message to [EMAIL
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 message to [EMAIL PROTECTED]
More majo
/ (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 message to [EMAIL PROTECTED]
More majordomo info at http
35 matches
Mail list logo
