Messages in this thread |  | | Date | Fri, 13 Dec 1996 18:03:53 -0500 (EST) | From | "Adam D. Bradley" <> | Subject | Re: QUOTA |
| |
On Fri, 13 Dec 1996, Craig Milo Rogers wrote:
> Just for the sake of discussion, suppose there were a special > /tmp filesystem that created (in effect) a separate /tmp directory for > each user (or, even more radically, each process group).
Hmm...curious. Some apps use /tmp for kludgy IPC, tho, between a single user's processes (PVM?) and between users... (aren't there some programs that set up sockets/pipes in /tmp?)
> Presumably > for this to really work properly, there would have to be some messy > hack to allow set-UID programs to access the union set of the /tmp > files of their real, effective, etc. UIDs; this brings up a potential > name collision problem, of course. Nevertheless, there ought to be > a substantial increase in system security from this relatively simple > approach.
The evils of "overlap" filesystems got thrown around here just last week...messy stuff. Also, a lot of the security concerns that have come up so far (link followed by bad SUID's) are cleared up just by having simple separate filesystems (making hard links impossible).
If we were to try something like this (perhaps as a compile option for really AR providers, schools, etc), try out this idea: why not make "/tmp" a symlink to "/proc/tmpdir", which is in turn a self-updating symlink (like "/proc/self") to "/tmpspace/tmp[UID]". This, of course, opens up the problem of which UID to use w/ SUID binaries; I would tend towards the real UID, so it is consistent for a given user. And it still breaks anything that uses /tmp for inter-user IPC, etc.
Just rambling...
Adam -- He feeds on ashes; a deluded mind has led him Adam Bradley, UNCA Senior astray, and he cannot deliver himself or say, Computer Science "Is there not a lie in my right hand?" Isaiah 44:20 bradley@cs.unca.edu http://www.cs.unca.edu/~bradley <><
|  |