Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262419AbVCWN6V (ORCPT ); Wed, 23 Mar 2005 08:58:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262398AbVCWN6U (ORCPT ); Wed, 23 Mar 2005 08:58:20 -0500 Received: from duempel.org ([81.209.165.42]:50375 "HELO swift.roonstrasse.net") by vger.kernel.org with SMTP id S261468AbVCWNyC (ORCPT ); Wed, 23 Mar 2005 08:54:02 -0500 Date: Wed, 23 Mar 2005 14:53:17 +0100 From: Max Kellermann To: linux-kernel@vger.kernel.org Subject: Re: forkbombing Linux distributions Message-ID: <20050323135317.GA22959@roonstrasse.net> Mail-Followup-To: linux-kernel@vger.kernel.org References: <20050322112628.GA18256@roll> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1110 Lines: 29 On 2005/03/22 12:49, Jan Engelhardt wrote: > What if the few procs that he may spawn also grab so much memory so > your machine disappears in swap-t(h)rashing? The number of processes is counted per user, but CPU time and memory consumption is counted per process. Going around RLIMIT_CPU is too easy by simply forkbombing. This renders RLIMIT_CPU unusable. The memory limits aren't good enough either: if you set them low enough that memory-forkbombs are unperilous for RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious applications. Now what about per-user (or per-session) CPU and memory limits? Another idea: RLIMIT_FORK (number of allowed fork() calls in that session). While that may not be useful for interactive login sessions, I can imagine several situations where it could help (like qmail child processes). Max - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/