Subject: RE: Per-user temp storage
To: 'David Brownlee' <email@example.com>
From: Bill Rees <firstname.lastname@example.org>
Date: 02/24/1997 09:10:16
This kind of race condition points to bugs in the file system code
namely link counts and lack of proper locks. To change the semantics of
/tmp in order to fix this is going to make tons of scripts break,
confuse users and provide nothing but a hack fix at best.
Is there a reasonably accurate list of bugs surrounding /tmp? If so,
how many can be classified as "race" conditions and probably be fixed
directly in the file system?
>From: Perry E. Metzger[SMTP:email@example.com]
>Sent: Monday, February 24, 1997 7:34 AM
>To: David Brownlee
>Cc: tech-kern@NetBSD.ORG; tech-security@NetBSD.ORG
>Subject: Re: Per-user temp storage
>David Brownlee writes:
>> On Mon, 24 Feb 1997, Frank van der Linden wrote:
>> > I don't think modifying a filesystem in this way is a good idea at all;
>> > it's something that should not be in the kernel. As soon as you start
>> > plugging holes by modifying the kernel, while there is a good userspace
>> > solution possible (i.e. mkstemp(3)), then you're on the wrong track.
>> It would help if at least source in the tree used mkstemp() rather
>> than mktemp(), tmpnam(), tempnam().
>> Maybe add a warning for the above functions in a similar fashion
>> to 'gets()' - I believe OpenBSD did something like that a while
>This is certainly useful, but it doesn't solve the "play with symlinks
>and deep directories during nightly find" problem.