Re: forkbombing Linux distributions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2005-03-24 at 02:05 +0900, aq wrote:

> I agree that make kernel more restrictive by default is a good approach.

Thank you! For a moment I thought I was the only human on this planet
who thought that.

Next question is where and how and what is an appropiate limit? I have
not heard any better suggestions than this:

--- kernel/fork.c.orig  2005-03-02 08:37:48.000000000 +0100
+++ kernel/fork.c       2005-03-21 15:22:50.000000000 +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 least 20 threads to boot a system


(FYI: A few lines below the default RLIMIT_NPROC is calculated from
max_threads/2)

This would give default maximum number of processes from the amount of
low memory:

RAM     RLIMIT_NPROC
64MiB   256
128MiB  512
256MiB  1024
512MiB  2048
1GiB    4096

That would be sufficent for the users to play their games, compile ther
stuff etc while it would protect everyone from that classic shell fork
bomb by default.

Actually, 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 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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux