Date: Wed, 07 Jun 2000 20:05:32 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Bengt Richter <bokr@accessone.com> Cc: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, freebsd-security@FreeBSD.ORG Subject: Re: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <200006080306.e5836GM02334@cwsys.cwsent.com> In-Reply-To: Your message of "Wed, 07 Jun 2000 18:35:56 PDT." <3.0.5.32.20000607183556.00908730@mail.accessone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <3.0.5.32.20000607183556.00908730@mail.accessone.com>, Bengt Richter writes: > 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. Except that $HOME is not understood in the kernel. This would overly complicate the kernel. A simpler approach would be to have a /tmp address space that would be addressable by any process with the same UID. When the last process belonging to a UID terminates, the UID's /tmp address space would be freed, deleting any files in the UID's /tmp. Only the UID and root would have access to the UID's /tmp. Root would have access via a portal-like filesystem that would map all users /tmp filesystems. Rather than having the kernel manage this new filesystem, have an automounter-like process manage the filesystem. This way the filesystem could be mapped to a users subdirectory implementing the policy outlined above and making the auto cleanup discussed above optional. Rather than implementing the policy I outlined above this same daemon could be used to implement the policy you outlined. The beauty of this is that flexible, even individualised policy definition and complexity would now be external to the kernel, using the same kernel interface that amd uses. We have a base of code to start with too: amd. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/DEC Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC 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?200006080306.e5836GM02334>