From owner-freebsd-security Wed Jun 7 6: 5:15 2000 Delivered-To: freebsd-security@freebsd.org Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by hub.freebsd.org (Postfix) with ESMTP id 6C68937B93C for ; Wed, 7 Jun 2000 06:05:11 -0700 (PDT) (envelope-from david.dagon@mindspring.com) Received: from mindspring.com (user-38ld0dk.dialup.mindspring.com [209.86.129.180]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id JAA08185; Wed, 7 Jun 2000 09:04:55 -0400 (EDT) Message-ID: <393E4B39.354DCDA4@mindspring.com> Date: Wed, 07 Jun 2000 09:16:41 -0400 From: David Dagon Reply-To: dagon@cc.gatech.edu X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.3.99-pre7 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Williams Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) References: <200006070424.e574Od303232@cwsys.cwsent.com> <200006070655.XAA97086@apollo.backplane.com> <393E3710.363AC6CF@geekspace.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Chris Williams wrote: > > I have to wonder, with all this discussion about one tmp being cleared > at boot and the other not...Do FreeBSD users really reboot so often that > this is an important case? ;) > In the late 70s, /tmp was frequently on a small, fast disk, often a RAM disk. It was usually used for small, quick access jobs, such as output from the multiple passes of cc. /usr/tmp (now /var/tmp) was slower, but often with larger capacity, and was used for jobs like sort, and such. The hier(7) pages only give reboot as a key difference between the two. But some systems may been configured to give faster access to /tmp. (Others might just as well be soft linked to /var/tmp, but that's up to the sysadmin.) So expected speed of access and general lifetime of the files are two factors that hier(7) does not discuss. I think you've made an excellent point. In these days where a single-spindle holds gigs and gigs, and the entire system resides on a single drive, the separation between /tmp and /var/tmp seems less important. And of course depending on a reboot as part of system security does not seem wise. On this matter, I reread with interest McKusick (et al.)'s book on 4.4BSD: Use of dedicated memory to support a RAM disk exclusively is a poor use of resources. The system can improve overall throughput by using the memory for the locations with high access rates. . . . [in efficiency of memory-to-memory copy noted for RAM storage] . . . The 4.4BSD system avoids these problems by building its RAM-disk filesystem in pageable memory, insted of in dedicated memory. The goal is to provide the speed benefits of a RAM disk without paying the performance penalty . . . The /tmp filesystem can be allocated a virtual address space that is larger than the physical memory on the machine. s. 8.4. (Yes, yes, there are differences between FreeBSD and 4.4). It seems that the idea behind /tmp is that it's supposed to be fast. This could mean a RAM disk, an MFS (ack!), or even just locating /tmp on another spindle so it does not contend with /usr traffic. Since it competes for resources, /tmp is cleaned regularly (most often, but not exclusively, after a reboot). One should use /tmp for transient or easily recreated information. So, it strikes me that there are still differences between /tmp and /var/tmp--expected speed of access (which may be a myth these days), and the anticipated lifetime of transient files. Maybe most sysadmins don't care to honor this distinction, and just sym link the two. But having two systems allows for tweaks. -- David dagon@cc.gatech.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message