From owner-freebsd-hackers Fri Jan 21 4:57:56 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.nyct.net (bsd4.nyct.net [204.141.86.6]) by hub.freebsd.org (Postfix) with ESMTP id CBD2514BB7 for ; Fri, 21 Jan 2000 04:57:52 -0800 (PST) (envelope-from mbac@nyct.net) Received: from bsd1.nyct.net (mbac@bsd1.nyct.net [204.141.86.3]) by mail.nyct.net (8.8.8/8.8.7) with ESMTP id HAA20040; Fri, 21 Jan 2000 07:57:51 -0500 (EST) (envelope-from mbac@nyct.net) Received: from localhost (mbac@localhost) by bsd1.nyct.net (8.8.8/8.9.3) with ESMTP id HAA06364; Fri, 21 Jan 2000 07:57:50 -0500 (EST) (envelope-from mbac@nyct.net) X-Authentication-Warning: bsd1.nyct.net: mbac owned process doing -bs Date: Fri, 21 Jan 2000 07:57:50 -0500 (EST) From: Michael Bacarella To: Doug White Cc: Matthew Reimer , freebsd-hackers@FreeBSD.ORG Subject: Re: RLIMIT_NPROC can be exceeded via setuid/exec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 21 Jan 2000, Doug White wrote: > On Thu, 20 Jan 2000, Matthew Reimer wrote: > > Background: in an attempt to manage our webserver to keep too many CGIs > > from taking down the machine, I've been experimenting with RLIMIT_NPROC. > > This appears to work fine when forking new processes, causing the fork > > to fail with error EAGAIN. > > > > However, this didn't solve our problem. We're using Apache with suexec, > > and still CGIs would multiply far beyond the specified resource limit. > > > > Apache forks suexec, which is suid root; fork1() increments the number > > of processes for root, unless RLIMIT_NPROC has been exceeded, in which > > case the fork fails with EAGAIN. > > > > suexec calls then calls setuid() (before it calls execv), which > > decrements root's process count and increments the target user's process > > count, but RLIMIT_NPROC is not consulted, and voila, we've just exceeded > > the target user's maximum process count. I was considering this same problem a few nights ago. My solution, (which was more to prevent a forkbomb-via-network) is to just restrict the maximum number of connections to something reasonable. As long as your cgis spawn a predictable number of subprocesses (say, NPROC), you can usually guesstimate that if you want no more than 100 processes: MAX_CONNECTIONS * NPROC = 100 Of course, if they're not at all predictable, that sucks. I'd probably try exploring running apache as a specific user (binding it to port say, 8080) and letting old fashioned UNIX limits kick in. You'd be avoiding suexec because it'd already be running at the desired userlevel. Authbind might be worth pursuing, except: a> I only know of it via hearsay b> It might be Linux only If that didn't work, I'd consider Linux and hope capabilities were implemented. It seems awkward that such a simple concept is such a pain in the ass to implement in bullet-proof fashion. Welcome to UNIX :) -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message