Date: Fri, 9 Jun 2000 03:03:02 -0400 From: "Matthew B. Henniges" <matt@axl.net> To: <freebsd-security@FreeBSD.ORG> Subject: RE: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <KBEAJDGMGMDNDPICHDNHAEPDFJAA.matt@axl.net> In-Reply-To: <3.0.5.32.20000607183556.00908730@mail.accessone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
And what of suid programs? Do they use the users tmp(and possible fall to symlink/race/whatever..) or do they use a different one(roots?) do suid programs all use roots /tmp, no matter who runs them? Matthew B. Henniges CoPresident Axl.net Communications http://www.axl.net (203) 552-1714 > -----Original Message----- > From: owner-freebsd-security@FreeBSD.ORG > [mailto:owner-freebsd-security@FreeBSD.ORG]On Behalf Of Bengt Richter > Sent: Wednesday, June 07, 2000 9:36 PM > To: Cy Schubert - ITSD Open Systems Group > Cc: freebsd-security@FreeBSD.ORG > Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) > > > 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 > 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?KBEAJDGMGMDNDPICHDNHAEPDFJAA.matt>