in reply to Re: mkdir with variable mask
in thread mkdir with variable mask

Well, I think, you could consider to use chmod directly after successful creation of the new directory


Yes, that seems to be the better option. Thanks.

At the conception stage I thought, that by giving mkdir the mode directly I could save one command. But that was before I learned about 'umask' and it all got more and more complicated.

And, thanks for the pointer to catfile. I will use this in the future.

BTW: What exactly is umask for? To me it seems like my system tries to tell me how I should set my permissions - which I don't really like. And it has no real point as a security measure if you can just reset the value or even chmod the resulting dir/file any way you like.

Alex

Replies are listed 'Best First'.
Re^3: mkdir with variable mask
by ikegami (Patriarch) on Jan 26, 2009 at 14:55 UTC

    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.

Re^3: mkdir with variable mask
by MidLifeXis (Monsignor) on Jan 26, 2009 at 15:29 UTC

    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

      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).

        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.

        --MidLifeXis