From owner-freebsd-security Wed Jun 7 4:44:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by hub.freebsd.org (Postfix) with ESMTP id 0D4BF37B657 for ; Wed, 7 Jun 2000 04:44:45 -0700 (PDT) (envelope-from netch@lucky.net) Received: from netch@localhost by burka.carrier.kiev.ua id ORB91449; Wed, 7 Jun 2000 14:44:22 +0300 (EEST) (envelope-from netch) Date: Wed, 7 Jun 2000 14:44:21 +0300 From: Valentin Nechayev To: Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <20000607144421.A82711@lucky.net> Reply-To: netch@lucky.net References: <200006070424.e574Od303232@cwsys.cwsent.com> <200006070655.XAA97086@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200006070655.XAA97086@apollo.backplane.com>; from dillon@apollo.backplane.com on Tue, Jun 06, 2000 at 11:55:03PM -0700 X-42: On Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Tue, Jun 06, 2000 at 23:55:03, dillon wrote about "Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)": > Maybe on your system it is, but try running a multi-user system that > way and you will quickly find your /var/tmp filled up to the brim. Or, Of course, of course. It is general problem of any public-accessable resource. Do you think you can really fix this world? Or do you try to emit /tmp as philosophical category? > MFS is a terrible idea for /tmp. Each page in an MFS filesystem eats > *TWO* pages of physical memory (until swapped). This means that the It is problem of one broken realization, isn't it? -- NVA To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message