From owner-freebsd-bugs  Mon Jan  3  9: 0:10 2000
Delivered-To: freebsd-bugs@freebsd.org
Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21])
	by hub.freebsd.org (Postfix) with ESMTP id 5ED0C151DD
	for <freebsd-bugs@FreeBSD.org>; Mon,  3 Jan 2000 09:00:02 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
Received: (from gnats@localhost)
	by freefall.freebsd.org (8.9.3/8.9.2) id JAA12556;
	Mon, 3 Jan 2000 09:00:02 -0800 (PST)
	(envelope-from gnats@FreeBSD.org)
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
Reply-To: kbyanc@posi.net
To: FreeBSD-gnats-submit@freebsd.org
X-Send-Pr-Version: 3.2
Subject: kern/15860: patch to make default kern.maxfilesperproc < kern.maxfiles
Sender: owner-freebsd-bugs@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org


>Number:         15860
>Category:       kern
>Synopsis:       patch to make default kern.maxfilesperproc < kern.maxfiles
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan  3 09:00:01 PST 2000
>Closed-Date:
>Last-Modified:
>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:
>Unformatted:


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message