Date: Wed, 07 Jun 2000 18:35:56 -0700 From: Bengt Richter <bokr@accessone.com> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> Cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <3.0.5.32.20000607183556.00908730@mail.accessone.com> In-Reply-To: <200006071311.e57DBsW08744@cwsys.cwsent.com> References: <Your message of "Wed, 07 Jun 2000 14:44:21 %2B0300." <20000607144421.A82711@lucky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.20000607183556.00908730>