in reply to mkdir with variable mask

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

untested quickshot of my thoughts:

#! /usr/bin/perl
use strict;
use warnings;
# added:
use File::Spec::Functions qw( catdir );

my $dir = '/home/me/perl-stuff/";
my $mode = (stat $dir)[2];

# better use File::Spec::catfile
#$dir .= 'testdir';
$dir = catdir( $dir, 'testdir' );

mkdir( $dir, $mode ) or die "$!\n"; # update2: $mode added
chmod( $mode, $dir ) or die "$!\n";

[download]

updates

  1. code example updated, because I did some testing.
  2. Considered ikegami's reply...
  3. strike-tags adjusted
  4. catfile replaced with catdir; thanks kreetrapper

Replies are listed 'Best First'.
Re^2: mkdir with variable mask
by kreetrapper (Scribe) on Jan 26, 2009 at 14:44 UTC
    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
[reply]

      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.

      --MidLifeXis

[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

        [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]

In Section Seekers of Perl Wisdom