OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug)
From: Cy Schubert - ITSD Open Systems Group (Cy.Schubertuumail.gov.bc.ca)
Date: Wed Jun 07 2000 - 02:42:32 CDT

In message <200006070655.XAA97086apollo.backplane.com>, Matthew Dillon
writes:
> :> also, the BSD/OS mfs proposal is not that god. This limits the size of /tm
> p,
> :> and uses mfs for things that do not need to be in mfs.
> :> the first thing I used to do on BSD/OS was to remove the mfs mount and to
> :> softlink /var/tmp to /tmp.
> :
> :I disagree with this. /tmp is cleared at boot while /var/tmp is not.
> :The reason for this is to have files remain across boot.
> :mfs is generally (arguably on some O/S's) faster than writing data to
> :disk. (If writing to disk is faster than using mfs, assuming there's
>
> 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
> active dataset (what processes have accessed recently) eats twice
> as much physical memory as it needs to. MFS also needlessly loads
> down the VM system when it does start to stress memory. Simple
> things like someone tar xvf'ing a large distribution in /tmp can bring
> the machine to its knees with an MFS partition where the same operation
> on a normal filesystem would barely glitch most of the resource meters.
>
> MFS would be my *LAST* choice for a tmp.

Is this because one page is in the cache and the other is in MFS? I
can see that would be a problem.

>
> Like it or not, /tmp and /var/tmp are here to stay. /usr/tmp doesn't
> exist on most systems (thank god!), so it would be stupid of us to add
> it in.

I didn't say that I wanted /usr/tmp! /usr/tmp is an ancient idea that
was replaced by /var/tmp in the last ice age. Why would we want
/usr/tmp? If we're going to do that let's have a /usr/spool and
/usr/adm.

/tmp and /var/tmp doesn't hold much water either. Most applications
support the use of TMP and TMPDIR environment variables. Applications
that don't support a TMP environment variable should be changed. /tmp
and /var/tmp is a concept that is past its prime and should be retired
lieu of a more secure paradigm. Anything less than this must be
considered unacceptable in a secure operating system.

So far no one has convinced me that /tmp and/or /var/tmp cannot be
phased out. I have not seen any good arguments to keep them over the
long term. Don't forget, applications can be changed to use the new
paradigm.

Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Team Leader, Sun/DEC Team Internet: Cy.Schubertosg.gov.bc.ca
Open Systems Group, ITSD, ISTA
Province of BC

To Unsubscribe: send mail to majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message