> 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 <><