Bugtraq mailing list archives
Re: where user temp files should go, env var names
From: "Jay R. Ashworth" <jra () BAYLINK COM>
Date: Thu, 21 Dec 2000 15:06:29 -0500
On Thu, Dec 21, 2000 at 11:30:19AM +0100, Peter J . Holzer wrote:
On 2000-12-19 00:55:34 -0500, Mike A. Harris wrote:On Tue, 19 Dec 2000, Aaron Drew wrote:I wouldn't envisage a kernel patch to give each tty or user its own virtual /tmp being be THAT hard to do.The kernel doesn't differentiate between directories in the filesystem. For all the kernel cares /tmp is where user directories are stored. The kernel doesn't ever know or treat differently any names of dirs in the filesystem.It shouldn't treat directories differently based on the *name*. Some unixes have/had a "hidden directories" feature. If a flag is set on a directory, any attempt to access the directory would instead access one of its subdirectories, depending on some other factor. DomainOS and some versions of Minix used this to keep different binaries in the "same" place. So, for example, on DomainOS, you would have /usr/bin/sysv/ps and /usr/bin/bsd/ps, and depending on whether you were running it in SysV or BSD mode, you would get one or the other executable when executing /usr/bin/ps. HP-UX inherited the feature from Domain-OS, but I can't recall whether it was used for anything useful. HP-UX 11 doesn't seem to have it anymore, anyway. Similarly, instead of a "OS mode", the subdirectory could be based on the user-id, so if /tmp has the "hidden-subdirs-are-userids" bit set, an access to /tmp/mutt.12345.msg would in fact access /tmp/1010/mutt.12345.msg, if my uid is 1010.
Indeed. but it's worth remembering part of the point is *using* /tmp in some circumstance is that *it is public*. It is a good place to park files which need to be shared by multiple programs being run on the same machine by different users. Now, granted, this is no longer the best way to *do* IPC, but it did get done in the past, and it could be considered part of the "semantics of Unix", if you like.
This definitely has nothing at all to do with the kernel whatsoever. It is a userland programming issue. The kernel does not impose policy decisions upon systems, that is what a sysadmin is for. Fix the programmer."mechanism, not policy", right. However, the kernel can provide a mechanism. Whether it is the right one (personally, I found those hidden directories rather confusing) is debatable. Especially since there is another mechanism in userland (the TMPDIR environment variable) which has almost the same effect, if it is used.
Yup, usually set by the user, but at least *visible* to that user so that he or she can unset it if they find the need to run a program that expects a shared /tmp. Cheers -- jra -- Jay R. Ashworth jra () baylink com Member of the Technical Staff Baylink The Suncoast Freenet The Things I Think Tampa Bay, Florida http://baylink.pitas.com +1 727 804 5015
Current thread:
- [hacksware]Pine temporary file hijacking vulnerability JW Oh (Dec 12)
- Re: [hacksware]Pine temporary file hijacking vulnerability Thomas Corriher (Dec 13)
- Re: where user temp files should go, env var names Peter W (Dec 14)
- Re: where user temp files should go, env var names Andrzej Chabierski (Dec 16)
- Re: where user temp files should go, env var names Valdis Kletnieks (Dec 18)
- Re: where user temp files should go, env var names Aaron Drew (Dec 18)
- Re: where user temp files should go, env var names Mike A. Harris (Dec 19)
- Re: where user temp files should go, env var names Nick Phillips (Dec 21)
- Re: where user temp files should go, env var names Peter J . Holzer (Dec 21)
- Re: where user temp files should go, env var names Doug Wyatt (Dec 21)
- Message not available
- Re: where user temp files should go, env var names Jay R. Ashworth (Dec 21)
- Re: where user temp files should go, env var names Peter W (Dec 14)
- Re: [hacksware]Pine temporary file hijacking vulnerability Thomas Corriher (Dec 13)
- Re: [hacksware]Pine temporary file hijacking vulnerability Christopher X. Candreva (Dec 14)