From kbyanc@kronos.alcnet.com  Mon Jan  3 08:58:19 2000
Return-Path: <kbyanc@kronos.alcnet.com>
Received: from kronos.alcnet.com (kronos.alcnet.com [63.69.28.22])
	by hub.freebsd.org (Postfix) with ESMTP id D3DC11516C
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  3 Jan 2000 08:58:14 -0800 (PST)
	(envelope-from kbyanc@kronos.alcnet.com)
Received: (from kbyanc@localhost)
	by kronos.alcnet.com (8.9.3/8.9.3/antispam) id LAA12448;
	Mon, 3 Jan 2000 11:58:02 -0500 (EST)
Message-Id: <200001031658.LAA12448@kronos.alcnet.com>
Date: Mon, 3 Jan 2000 11:58:02 -0500 (EST)
From: kbyanc@posi.net
Sender: kbyanc@kronos.alcnet.com
Reply-To: kbyanc@posi.net
To: FreeBSD-gnats-submit@freebsd.org
Subject: patch to make default kern.maxfilesperproc < kern.maxfiles
X-Send-Pr-Version: 3.2

>Number:         15860
>Category:       kern
>Synopsis:       patch to make default kern.maxfilesperproc < kern.maxfiles
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kbyanc
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan  3 09:00:01 PST 2000
>Closed-Date:    Thu Dec 13 13:24:46 PST 2001
>Last-Modified:  Thu Dec 13 13:26:41 PST 2001
>Originator:     Kelly Yancey
>Release:        FreeBSD 3.2-STABLE i386
>Organization:
>Environment:

	FreeBSD 3.2-STABLE i386

>Description:

	Kern.maxfilesperproc defaults to the same value as kern.maxfiles
	(MAXFILES in sys/conf/param.c). However, as noted in multiple
	threads on the -hackers mailing list this behaviour can cause a
	rogue process to runaway without root being able to kill it.
	Admittingly, this is purely the admin's fault for not setting
	limits, but there is no good reason to have the system default to
	a state that allows this to occur.

>How-To-Repeat:
>Fix:
	
	The simple patch below reduces the maxfilesperproc to initially be
	less than maxfiles. The number 20 was more or less pulled out of
	thin air and feel free to adjust it, so long as the change gets
	made. I picked twenty simply because it is less than the minimum
	value of MAXFILES (which is 2*NPROC which is 72 when MAXUSERS is
	1) and should be enough for root to login and run ps/kill.

		- Kelly

--- sys/conf/param.c.orig	Mon Jan  3 11:34:59 2000
+++ sys/conf/param.c	Mon Jan  3 11:38:44 2000
@@ -80,7 +80,7 @@
 int	maxproc = NPROC;			/* maximum # of processes */
 int	maxprocperuid = NPROC-1;		/* maximum # of processes per user */
 int	maxfiles = MAXFILES;			/* system wide open files limit */
-int	maxfilesperproc = MAXFILES;		/* per-process open files limit */
+int	maxfilesperproc = MAXFILES - 20;	/* per-process open files limit */
 int	ncallout = 16 + NPROC + MAXFILES;	/* maximum # of timer events */
 
 /* maximum # of mbuf clusters */


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->kbyanc 
Responsible-Changed-By: dd 
Responsible-Changed-When: Sun Jul 22 08:24:28 PDT 2001 
Responsible-Changed-Why:  
over to originator 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15860 
State-Changed-From-To: open->closed 
State-Changed-By: kbyanc 
State-Changed-When: Thu Dec 13 13:24:46 PST 2001 
State-Changed-Why:  
Obsoleted by rev 1.48 of src/sys/kern/subr_param.c: 
Limit maxprocperuid to 9/10 maxproc, and limit maxfilesperproc to 
9/10 maxfiles.  This should make local resource exhaustion attacks 
to handle with a non-tweaked setup. 


http://www.FreeBSD.org/cgi/query-pr.cgi?pr=15860 
>Unformatted:
