Re^3: mkdir with variable mask

To add to what ikegami said...

Using umask plus the permission parameter to mkdir allows you to further avoid some potential race conditions. Along with executable stacks being exploited with buffer overflows, race conditions have been, at least by my memory, a significant contributor to security exploits.

It may be worth the couple of extra minutes to code the umask stuff and skip the chmod, especially if you do not have a full handle on how your code may be used in the future.

--MidLifeXis

Comment on Re^3: mkdir with variable mask Download Code

Replies are listed 'Best First'.
Re^4: mkdir with variable mask by ikegami (Patriarch) on Jan 26, 2009 at 17:45 UTC
To avoid the race condition, you start off with few permissions, then use `chmod` to increase them if necessary. Normally, you accept the fewer permissions because that's what the user requested (via `umask`). `mkdir($qfn, $desired_perms) or die; chmod($desired_perms, $qfn) or die; # Override user's umask` [download] It's messing with `umask` can lead to race conditions (in asynchronously execute code such as threads and signal handlers).	[reply] [d/l] [select]
Re^5: mkdir with variable mask by MidLifeXis (Monsignor) on Jan 26, 2009 at 18:05 UTC
Very true, very true. Wasn't thinking of the case of threads and signals. Like you said, however, you start with permissions equal or higher than you want, and reduce the restrictions when ready to open it up, not the other way around. I just reread my post, and yeah, it did not say what I was thinking. Ugh. The specific cases I was thinking of for security bugs were cases where this sequence of code was executed: `umask(000); mkdir($dir, 0777); # or creating a file mode 0666, etc ... ... chmod($dir, $mode);` [download] or even the same thing with creating files. By restricting the mode to just what you need to be able to set up your files / directories (`umask(0077)`), and then opening it up once setup is complete (`chmod(...)`), you can more easily avoid some of these situations. But as you stated, you need to be aware of these restrictions in your asynchronous areas of your code. --MidLifeXis	[reply] [d/l] [select]