On Apr 28, 2009, at 5:15 PM, Kyle Sluder wrote:
Except in the case where one line of code creates the temp file and
then another immediately uses it and deletes is - as in my case.
There is zero chance the user could FUS faster than my 2 lines of
code create and delete the file.
By virtue of you saying that, it will happen. Murphy's Law loves race
conditions because it always wins.
Not to mention that an attacker putting your app under pressure will
use nasty tricks to purposely trigger the race condition. Apple has a
surprisingly comprehensive guide to filesystem (and other) security
issues, whose advice they blatantly ignore, but you should follow:
http://developer.apple.com/documentation/Security/Conceptual/SecureCodingGuide/Introduction.html
One of my personal gripes: If you look at the implementation of, say,
mkstemp() and tmpfile() down at the Libc level, you find that
tmpfile() is implemented *in terms of* mkstemp(). Unfortunately for
some, tmpfile() also wraps the FD from mkstemp() in a FILE, when I
want a NSFileHandle. [NSFileHandle
initWithFileDescriptor:fileno(tmpfile()) closeOnDealloc:NO]. Oops, now
I have to keep track of the FILE* for as long as the NSFileHandle*
exists. Ugh! My eventual solution was to roll my own method as a
category on NSFileManager:
- (NSFileHandle *)openSecureTemporaryFileAndReturnError:(NSError
**)outError;
This method does all the exclusive atomic opening and unlinking and
returns a nice NSFileHandle or NSError instead of mucking around with
errno.
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
