|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: /tmp
From: Dan Stromberg (strombrg
NIS.ACS.UCI.EDU)Date: Fri Dec 22 2000 - 10:42:27 CST
- Next message: sporty o'one: "Re: Oracle WebDb engine brain-damagse"
- Previous message: Richard M. Smith: "CERT's ActiveX security report"
- Maybe reply: Dan Stromberg: "Re: /tmp"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Dec 22, 2000 at 11:26:13AM +0100, Michal Zalewski wrote:
> Please tell me why are you considering /tmp as the only one solution?
> Moving runtime temporary files that do not *have* to be shared from /tmp
> to eg. ~/tmp is pretty good solution, as well. Unfortunately, this won't
> solve numerous problems of programs that are not following mk*temp()
> convention, creating eg. pid-based temporary files ;) On the other hand,
> most of context pseudo-filesystem / redirection solutions (like making
> real location of /tmp entries for every UID different) might broke eg. X
> server / clients functionality etc.
I am displeased with ~/tmp, because I believe constructing a reliable
~/tmp scrubber would be problematic.
Consider: what if most, but not all, of the home directories a machine
sees are NFS mounted? What if the NFS server is down when you try to
check ~/tmp to see if it is local?
What if the NFS server doesn't have a ~/tmp scrubber, and it might be
a pain to provide one? (possible example (really not sure) : netapp)
-- Dan Stromberg UCI/NACS/DCS
- application/pgp-signature attachment: stored
- Next message: sporty o'one: "Re: Oracle WebDb engine brain-damagse"
- Previous message: Richard M. Smith: "CERT's ActiveX security report"
- Maybe reply: Dan Stromberg: "Re: /tmp"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]