On Wed, Feb 3, 2010 at 12:30 PM, <[email protected]> wrote: >> If the calling code did not immediately use the temp file, >> the new functions close the descriptor returned from mkstemp(), >> but it does NOT delete the file. >> >> Since the file still exists, an external (different uid) process >> cannot create one in its place, so the race condition vulnerability >> does not exist. The file is just sitting there. > > Unfortunately, this is only true if the directory you're creating the file > in isn't writable by other processes - in other words, doing this in /tmp > isn't safe,
Standard procedure is to have the sticky-bit set on the system temp directory, so any files created in it can only be deleted/accessed by the owner (or root). But, yes, there are probably some f'ed up configurations out there. >but doing a 'umask 077; mkdir /tmp/$USER' and then > creating /tmp/$USER/$TMPNAME is safe. Sticky bit on the directory helps too, > but we probably should program defensively and get it right even if the > sysadmin failed to do so. Agree with philosophy, but the directory method does complicate cleanup, which requires more work. A descision to be made is the work I have currently done worth rejecting because it fails to address all (less probable) cases, or accept it now for something better than what currently exists and then improve upon it later? Since it has been years that nmh has existing with temporary file problem with no one fixing (a couple have tried and realized the worked involved so backed out), I think if there is any improvement to the current code base, it is worth accepting. > Otherwise, you're still open to a race condition - an attacker can just > rename the file you created, and then stick another file or even a symlink > in place of the old name: > > % ls -ld /tmp/foo > drwxrwxrwx. 2 root root 4096 Feb 3 09:30 /tmp/foo If you own the box, fix it. If not, complain to the sys admin. All my boxes have /tmp permissions set correctly, and it seems to be that way for stock Linux distros. Unsure about other unices out there, but I do remember many years ago having to fix /tmp permissions on solaris systems. Note, as of now, my latest changes default to user's mail dir for temp files. I'm not concerned about NFS, unless, there is some programs in nmh that are using temp files for locking/semaphore purposes. I do not use rcvstore, and related programs, so maybe someone can chime in if these programs use lock files or not. I can look at the code later, but I would like input from those that use such programs. --ewh _______________________________________________ Nmh-workers mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/nmh-workers
