Date: Mon, 4 Dec 2000 21:39:39 -0500 (EST) From: Matt Heckaman <matt@ARPA.MAIL.NET> To: "David G. Andersen" <dga@pobox.com> Cc: FreeBSD-SECURITY <freebsd-security@FreeBSD.ORG> Subject: Re: [spam score 10.00/10.0 -pobox] Re: Fw: NAPTHA Advisory Updated - BindView RAZOR Message-ID: <Pine.BSF.4.21.0012042134110.69763-100000@epsilon.lucida.ca> In-Reply-To: <200012050138.SAA03007@faith.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 4 Dec 2000, David G. Andersen wrote:
...
: Nope. It wasn't a kernel problem you were encountering - it was a
: systemwide resource limit being reached. It's not that there's a _bug_ in
: the kernel, it's that the processes file table limits weren't isolated
: from each other. The right solution to this is more isolation of
: different processes (e.g. resource control).
It would be nice if one could set login.conf(5) style resource limits per
daemon instead of per login. Thus we could say, well "{q,send}mail can
have 1024 fds" while apache can have 4096.. etc. Maybe there is a way to
do this (djb's tcpserver? xinetd?) but I'm not currently aware of one.
One thing though, it would be nice to see FreeBSD's default fd &
nmbcluster setting be raised, as it really isn't going to be enough for a
lot of people in normal use, and damn sure won't stand up to any kind of
attack like this. Just an opinion though :)
* Matt Heckaman - mailto:matt@lucida.qc.ca http://www.lucida.qc.ca/ *
* GPG fingerprint - A9BC F3A8 278E 22F2 9BDA BFCF 74C3 2D31 C035 5390 *
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (FreeBSD)
Comment: http://www.lucida.qc.ca/pgp
iD8DBQE6LFVsdMMtMcA1U5ARAkh/AKDmPOD28La1CY15lq/BiktuWW0kkACg3PN1
m/6arbHHdoLL412tfk8N6Hw=
=vJij
-----END PGP SIGNATURE-----
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012042134110.69763-100000>