From owner-freebsd-security Wed Jun 7 18:35:51 2000 Delivered-To: freebsd-security@freebsd.org Received: from dfw-smtpout2.email.verio.net (dfw-smtpout2.email.verio.net [129.250.36.42]) by hub.freebsd.org (Postfix) with ESMTP id 5C49F37B5AE for ; Wed, 7 Jun 2000 18:35:44 -0700 (PDT) (envelope-from bokr@accessone.com) Received: from [129.250.38.64] (helo=dfw-mmp4.email.verio.net) by dfw-smtpout2.email.verio.net with esmtp (Exim 3.12 #7) id 12zrEV-00003n-00; Thu, 08 Jun 2000 01:35:43 +0000 Received: from [204.250.68.168] (helo=gazelle) by dfw-mmp4.email.verio.net with smtp (Exim 3.12 #7) id 12zrET-00062s-00; Thu, 08 Jun 2000 01:35:42 +0000 Message-Id: <3.0.5.32.20000607183556.00908730@mail.accessone.com> X-Sender: bokr@mail.accessone.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Wed, 07 Jun 2000 18:35:56 -0700 To: Cy Schubert - ITSD Open Systems Group From: Bengt Richter Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200006071311.e57DBsW08744@cwsys.cwsent.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:11 2000-06-07 -0700 Cy Schubert - ITSD Open Systems Group wrote: [...] > >Replacement candidates for /tmp and /var/tmp are: > >1. Each user has a subdirectory in /tmp as /tmp/$USER. An idea brought > forth to BUGTRAQ by Theo de Raadt of the OpenBSD project. > >2. Each user maintains their own /tmp as $HOME/tmp or some such thing. > An idea I had discussed with my co-workers a number of years ago. > I have an inkling of a third way, for backwards compatibility with #2. Suppose you create a pseudo-device (/dev/home ?) whose only purpose is to support a pseudo-file-system, whose only purpose is to return $USER-dependent symbolic links? (A new kind of symbolic link might be more efficient, but I'm looking for a way to do it within current mechanisms). /dev/home/xxx would be mounted at /yyy to get the effect of opening /yyy/file to be opening $HOME/xxx/file. For our case, use tmp for both xxx and yyy. That's the sketch, anyway. The above deals with (hidden) partitioning of the /tmp namespace, but does not address the hint-carrying aspect of "tmp." As other posts have mentioned, "tmp" might mean: a. You want a fast small scratch file b. It might not be small c. You want garbage collection service d. Access may be very public, so think twice Other usage hints might be: e. You want sequential read-only access with huge read-ahead buffering for a jitter-glitch-free multimedia stream f. You want a no-persistent-cleartext-guaranteed file You can easily expand on this, but my point is that maybe namespace, access control, and performance tuning goals should be separated (at least for discussion purposes ;-) so that if there is going to be changes, solutions will be implemented in appropriate contexts. One way of specifying something about a file is by saying it applies to all files in a particular namespace (or subspace: e.g., leading dot, trailing .vbs :) or directory. Another is to mark the files with attribute flags or ACLs. Another is to pass arguments to access functions like open(), or ioctl(), etc. Another is to wrap it in some new object. Etc., etc. If we don't identify what we're doing, and the options, we won't think about them until a legacy pinches. HTH. Regards, Bengt Richter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message