On Wed, 2012-04-25 at 09:05 -0400, Hans Hübner wrote:
On Wed, Apr 25, 2012 at 8:42 AM, Stelian Ionescu sionescu@cddr.org wrote:
On Wed, 2012-04-25 at 06:26 -0400, Hans Hübner wrote:
Dealing with the umask has no place in this library. "umask" is a system-specific concept, and file security is something that is orthogonal to temporary files. If an application wishes to give its temporary files different permissions than other files that it creates, it should do so explicitly.
Quite the opposite, the permissions must be specified at creation time, otherwise it's useless
If the Lisp implementation provides a means to specify the file permissions to cl:open, then that would be how it should be done for temporary files, too. I do not understand what you mean by "quite the opposite" here. Is there anything in the proposed API that makes it impossible to specify file permissions, if so supported by the underlying implementation?
To achieve safety, the umask must be specified on creation. If cl:open doesn't allow that, then it's effectively useless for the purpose of properly creating temporary files
That's not how they do it. Windows and OSX have a user-specific temporary directory and applications usually create a subdirectory of their own but with a well-known name: see documentation for NSTemporaryDirectory, for example
Windows and OSX do better than Unix by default in that they have user specific temporary directories, and this is all that we're discussing anyway. The only isolation that one can hope to have is on a per-user level, i.e. one may want to prevent that a process running under a some user ID can access a (temporary or non-temporary) file created by a process running under a different user ID. By making the user-specific temporary directories inaccessible to other user IDs, this goal is neatly achieved.
The goal should be to protect, as much as possible, also against malicious programs running under the same UID and randomizing file and directory names, as opposed to using well-known names, is very useful in that regard