Date: Thu, 08 Jun 2000 11:15:01 -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.20000608111501.009018a0@mail.accessone.com> In-Reply-To: <200006080306.e5836GM02334@cwsys.cwsent.com> References: <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
At 20:05 2000-06-07 -0700 Cy Schubert - ITSD Open Systems Group wrote: >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 -------------------------^^^^[1]-------^^^^^^^ ^[1]: Oops, the /xxx info should not go there (nor as mount call opt where it actually would go). That would make it the same for all. Better from a config file with xxx for each user. Then a mount_home could do the whole setup job analogous to mount_mfs. >> 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. > I didn't mean for the kernel to have access to $HOME per se (ick). The /dev/home device driver would cache "$HOME" info passed to it during initialization. This would effectively create a file system on the device and write data to it. And it wouldn't be $HOME per se, it would be the default working directories from the password file, for every user. This could be done via an ioctl interface. This could all be bundled in mount_home. Per second thought above, there would be a config file to give each user a /tmp location relative to the default directory read from the pw file, BTW, this would mean that daemons like mysqld would/could make use of redirected /tmp as well. Giving /dev/home multiple units could allow multiple mounts for redirecting other mount points similarly. Putting a leading slash on the otherwise relative paths could be made to let you redirect to arbitrary locations (just thought of that), which might help integrate with some legacy situations. >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. > /dev/home and its file system would provide generalized redirection of any mount point to any point in a current user's default working directory tree (or anywhere), rather than being tmp-specific, so it's a different approach. >Rather than having the kernel manage this new filesystem, have an >automounter-like process manage the filesystem. This way the I thought mounting once would be simple, but that's interesting. I thought to pretend that /dev/home was a new type of memory file device, to allow making it as small and simple as possible, and make a file system do most of the work of interfacing. Alternatively, /dev/home could be intialized with what would amount to a compressed image of an ordinary very small mfs containing the links, (constructed to facilitate the hidden UID-dependent view generation) and mount that read-only as an apparently normal mfs, thus making use of an existing file system. An entry in fstab could kick off mount_home, unless maybe there is a problem timing the move from use of ordinary /tmp during startup to using UID-directed /tmp. >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. > I would wonder about overhead, and what it would take to make it work in non-NFS systems. What I had in mind was to do something as minimal as possible. Perhaps another round or two of comments would be productive. Seems like we're getting somewhere :) Regards, Bengt Richter BTW, is C++ (or are particular C++ features) verboten for writing device drivers or file systems? 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.20000608111501.009018a0>