From owner-freebsd-hackers Mon Feb 4 15:18:10 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail.slc.edu (Weir-01a.SLC.Edu [198.83.6.252]) by hub.freebsd.org (Postfix) with ESMTP id 51D7037B41C for ; Mon, 4 Feb 2002 15:17:38 -0800 (PST) Received: (from aschneid@localhost) by mail.slc.edu (8.11.6/8.11.6) id g14IHOt01696; Mon, 4 Feb 2002 18:17:24 GMT (envelope-from aschneid@mail.slc.edu) Date: Mon, 4 Feb 2002 18:17:24 +0000 From: Anthony Schneider To: Mike Makonnen Cc: Gaspar Chilingarov , freebsd-hackers@FreeBSD.ORG Subject: Re: fork rate limit Message-ID: <20020204181724.B1633@mail.slc.edu> References: <20020202201551.GA89061@mail.web.am> <200202022052.g12KqOM17214@apollo.backplane.com> <20020202223546.GA430@mail.web.am> <200202030754.g137saC40573@blackbox.pacbell.net> <20020203160433.A10920@mail.slc.edu> <20020203223946.B13336@mail.slc.edu> <20020204175616.A1056@mail.slc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020204175616.A1056@mail.slc.edu>; from aschneid@mail.slc.edu on Mon, Feb 04, 2002 at 05:56:16PM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've actually wanted something like this for a while and have considered coding it myself. Perhaps this could go into a login.conf variable (which I would have to create myself), but originally my plan was basically kill off parent processes with the uid of the user who is fork()'ing too often (200 per 10 seconds sounds good) simply hard-coded. Now, should this be available as a login.conf variable, and should the variable ever be used on a system other than my own, it could very easily be defaulted to something like :maxforks=3D0: for a 10 second timespan, and set to :maxforks=3D200: for the scenario we are talking about, perhaps assigned exclusively to student (or untrusted) accounts. So, by default, the limit will be ignored, and aside from the potential for poor implementation of th= is, the only side effect would be a default login.conf with an extra line, and perhaps a few extra lines in the login.conf manpage. Some people would like to limit this, and should they want to, they should be able to. People run public access systems (myself included) where fork bombs can put a huge load on the system before a sysadmin can finally pick out the perpetrator and zap him. This is a non-fatal, but VERY annoying scenario to deal with, and if it can be prevented, I say go for it. I believe that a few tweaks to fork1(), struct uidinfo and some others would do the trick. Gaspar, if you choose to go ahead with this and would like assistance (testing, coding), I'd be glad to help. Also, if anyone has any further input, I know that I'd be glad to hear about it. -Anthony. p.s. sincerest apologies for anyone who may have received several copies of this email. I've been having a few mail difficulties. On Sat, Feb 02, 2002 at 11:54:36PM -0800, Mike Makonnen wrote: > On Sun, 3 Feb 2002 02:35:46 +0400 > Gaspar Chilingarov wrote: >=20 > > I've got such situation on our free shellbox set up in the > > university - some newbies were kidding with old while(1) fork(); > > attack. Finnaly they got hit by memory limits set up for each > > user, but anyway they were taking a lot of processor time. I > > prefer to limit some uid's ability to do many forks in some > > short period - like 'no more than 200 forks in 10 seconds' or > > smthng like this. >=20 > Lock them out of the box for a while. If they do it again ban them > forever. The students will learn pretty quickly not to do such things. > This means less work for you, and no need to continuously maintain diffs > against the kernel sources. IMO it's a *very,very* bad thing to > introduce changes into the kernel that might introduce unintended side > effects when the problem can be solved administratively. >=20 >=20 > cheers, > mike makonnen >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjxe0DMACgkQ+rDjkNht5F2mBgCgmBKcKLwbARjh2pNkmUN08GIG vmgAnAjZIU8wU/AM/3+WRXelgu516Oi6 =Ch/R -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message