To me it seems like my system tries to tell me how I should set my permissions - which I don't really like.
Other way around. It's you telling the system how to limit permissions so you don't go around creating world accessible files everywhere. There's a system default, but you can override it in your login script.
| [reply] |
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.
| [reply] [d/l] |
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
It's messing with umask can lead to race conditions (in asynchronously execute code such as threads and signal handlers). | [reply] [d/l] [select] |
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);
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.
| [reply] [d/l] [select] |