(no subject)

[richard]

Sorry about the mess .... I'm away from home and trying to use a webmail system 
hope you can sort this out ...

On 4 Mar 2004, at 06:58, David Ayers wrote:

Sheldon Gill wrote:

/**
* Returns the name of a directory in which temporary files can be
stored.<br/ >
* For unix-like systems this is usually '/tmp'.<br/ >
* For MS-Windows systems this is the system temporary directory,
often '%WINDIR%\TEMP\'.<br/ >
*/
NSString
*NSTemporaryDirectory(void)

Why did you take out the creation of a secure subdirectory of temp?
This is a bigger question.
Firstly, the existing code isn't really secure. You can circumvent it. I looked 
at changing that but things start getting quite complex.

If it's not secure, it should be fixed.

Secondly, the OpenStep and Cocoa behaviour is simply to return the temporary 
directory.

That's incorrect ... on Cocoa (on my system) the behavior is to return a 
private temporary directory '/private/tmp/501/TemporaryItems'  where the '501' 
is my uid.

Now, what is the right behaviour from an API perspective?  Well, on one hand we 
want a place where we can create temporary files in a secure and safe way. 
Often, the goal is a temporary file. Pure and simple. No need for a whole 
directory.
On the other hand, sometimes we want to discover where {temp} actually is. For 
example, if I want to find "/tmp/.X11-unix".

We should *never* expect NSTemporaryDirectory() to tell us where X11 is storing 
its temporary files ... that would be an undocumented and unportable feature.  
We would be trying to do something that the api is not intended for.

Additionally, there are systems which use extended attributes and capabilities 
for more secure/flexible behaviour.
In light of these things, I think that the right thing for 
NSTemporaryDirectory() to do is to return the path to the temporary directory.

I strongly disagree ... the MacOS-X compatible way is to return a private 
temporary directory.  While it's true that the documentation doesn't say that 
the directory is private/secure, we should try to maintain compatible behavior 
rather than introducing a new incompatible one.

Thus it serves as the basis of all operations.
* If you want a secure directory in there write
MyTemporaryDirectory() which does the right things for your application and 
platform
* If you want a secure temp file write
MyCreateTempFile() which does the right things for your purposes
* If you want to find, use GSFindNamedFile( NSTemporaryDirectory(), 
".X11-unix", nil) or whatever
It does pave the way for a library of routines to do these things in various 
ways for various platforms but I think this is a good thing.
Creating a single use temporary file under POSIX is best done by calling 
(f)open with the create flag, limited mode and a difficult name to guess.
Doing the same conceptual thing under Win32 is different.
In short, I strove to make things more simple and straightforward. I feel this 
generally leads to more robust code that's both easier to use and maintain.

I can see how one can derive this from the documentation.  But IMO, this 
definitely needs a transition period for code relying on the secureness of 
NSTemporaryDirectory().  First we need a major release which introduces 
something like a GSSecureTemporaryDirectory(), have NSTemporaryDirectory() 
return that same directory and prominently announce that NSTemporaryDirectory() 
won't return a secured directory but the system directory in future releases.  
We can then consider changing NSTemporaryDirectory() for the following major 
release.

I believe we should try to make sure that the temporary directory *is* secure, 
and document this behavvior, rather than introducing a different behavior than 
MacOS-X.