bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSPathUtilities Patch - 8 - NSTemporaryDirectory


From: Sheldon Gill
Subject: NSPathUtilities Patch - 8 - NSTemporaryDirectory
Date: Tue, 20 Apr 2004 12:59:50 +0800
User-agent: KMail/1.6.1

NSTemporaryDirectory() consideration

A number of people believe that this function should return the location of a
_secure_ temporary directory for each user.

First and foremost for this position is the behaviour on MacOS X. On that
platform the system sets up per user directories in the form of
"/private/tmp/$UID/TemporaryItems" for each user. This isn't being done by 
Foundation, it's being done by the operating system. I think this is key 
here. The whole OS is geared for it.
Sure, NSTemporaryDirectory() will return that location. So will FindFolder() 
which is a Carbon call. It's coming from the OS.

My view is that gnustep-base is primarily a compatibility layer. As such it 
needs to defer to the platform it is running on for many operations and 
behaviour choices. The case of temporary space is, in my opinion, such an 
operation. I think that the right thing for the library to do is, as simply 
as possible, locate the temporary directory for that platform. That's it. 
Creating a per user directory for temporary space and securing it is best 
left to the OS.

Thus I feel it should be up to the packagers and users to decide on the policy 
for their system and implement that. GNUstep can provide tools and/or 
examples to facilite this, if desired. By adopting this approach:
* security issues are pushed to the platform level which is better suited for 
such considerations
* methods can vary to maximise use of services offered by platform
* GNUstep can more easily comply with variation in system policy/mechanism
* GNUstep library code is much more simple, smaller and faster.

Those wanting per user secured directories can easily do so for their system. 
Some possible strategies include:

nix-like SysAdmin level:
- make adduser add a securely created directory in temp space, named using uid 
or login name. An additional benefit of this is the possibility of setting 
per user limits on use of temp space (quota etc).
- modify login scripts to set TEMP, TMP or TMPDIR to point to the per user 
temp space

nix-like User level:
- modify login script to create secure temp directory. Can be in ~ or /tmp or 
anywhere else you'd like. Set TEMP, TMP, or TMPDIR accordingly.
- modify logout script to clean up properly

Win32
- Create a directory in temp (non roaming)
- Create a directory is user's profile space for temporary files (roaming)
- set file object acl with limited permissions only for the user SID
- Make GetTempPath() return this directory or set TEMP environment variable

Some operating systems can use additional mechanisms for better control like 
trustees or kernel enforced security policy. Where available, they should be 
used as they can provide better behaviour.

These options create the directory and set up the security as a one time 
operation. Preferably this is done by the System Administrator who is then in 
a position to act if there is a problem.
Even if it's done at user login time, it makes it easy to highlight an 
insecure situation for the user to respond. It is better for the user to be 
alerted _before_ running vulnerable applications and potentially exposing 
sensitive information.

Following this track will also add /tmp security for non-GNUstep applications 
because it's being done at the platform level.

I firmly believe that trying to pursue the current direction will add 
complexity and confusion where it should not go. The alternative path I'm 
offering provides better security and an easier, smaller GNUstep 
implementation. Why not go win/win?


Regards,
Sheldon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]