Date: Fri, 4 Jan 2008 13:26:37 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: freebsd-current@freebsd.org, Jason Evans <jasone@freebsd.org>, Poul-Henning Kamp <phk@FreeBSD.org> Subject: Re: sbrk(2) broken Message-ID: <20080104132437.U77222@fledge.watson.org> In-Reply-To: <86r6gxahwm.fsf@ds4.des.no> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <20080104002002.L30578@fledge.watson.org> <86wsqqaqbe.fsf@ds4.des.no> <20080104110511.S77222@fledge.watson.org> <86r6gxahwm.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-307192972-1199453197=:77222 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > Robert Watson <rwatson@FreeBSD.org> writes: >> Dag-Erling Sm=F8rgrav <des@des.no> writes: >>> Robert Watson <rwatson@FreeBSD.org> writes: >>>> The right answer is presumably to introduce a new LIMIT_SWAP, which=20 >>>> limits the allocation of anonymous memory by processes, and size it to= =20 >>>> something like 90% of swap space by default. >>> Not a good solution on its own. You need a per-process limit as well,= =20 >>> otherwise a malloc() bomb will still cause other processes to fail=20 >>> randomly. >> That was what I had in mind, the above should read RLIMIT_SWAP. > > You don't want the default to be so high. You want a low default, with t= he=20 > possibility for the admin to increase the limit for a particular user in= =20 > login.conf or similar without rebooting (which is currently not possible= =20 > since the default datasize =3D=3D maxdsiz, which can only be changed in t= he=20 > kernel config or loader.conf) I'm fine with also having global limits. > You may also want to have a collective limit for unprivileged users, so r= oot=20 > will still be able to log in if something goes wrong. This will presumably only work for console logins, as sshd (etc) will depen= d=20 on unprivileged users, but perhaps that is fine. I'm less concerned with t= he=20 details of the implementation or policy than that we simply be able to supp= ort=20 even a basic policy and have it configured by default to prevent=20 foot-shooting. Robert N M Watson Computer Laboratory University of Cambridge --621616949-307192972-1199453197=:77222--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080104132437.U77222>