Is there any technical merit/necessity to numerous *nix commands (mkdir, mkfifo, mknod) having a -m (--mode) option?

I ask this because near as I can tell, umask (both the shell command and the syscall) provides everything you need to control a file's permissions:

For example, I can do this:

mkdir -m 700 "$my_dir"

..but I can just as easily do:

old_umask=`umask` \
&& umask 0077 \
&& mkdir "$my_dir"
umask "$old_umask"

To be clear, I can see that the former is much more user-friendly and convenient (especially for command-line useage), but I don't really see a technical advantage of the former over the latter.

Note also that I understand the merits of this flexibility at the underlying syscall level: if I want to call open or sem_open or what have you with at most 600 permissions, it makes sense that I would just pass S_IRUSR | S_IWUSR to the open syscall, never bother with the umask syscall, saving a syscall round-trip (or two, if I want to then reset the umask since the umask call modifies the current umask) and my code is simpler/cleaner. This does not apply in the command line example because the -m/--mode option of such a command will have to call umask to zero out the umask of that command's process anyway, to ensure the mode/permission bits that it's supposed to set on the new file/whatever are set. (E.g. if my shell's umask is 022, then mkdir -m 777 /tmp/foo can only work as expected if it's first calling umask internally to zero out the umask it inherited from the shell.)

So what I want to make sure I didn't miss in my considering of the problem is, is there something you could not accomplish with just the umask command, without relying on the -m/--mode options of the mk* commands?

  • Note -m is not always equivalent to umask; mkdir -p, for example, only uses -m for the final directory and not intermediates.
    – None
    Jul 31, 2017 at 14:28

1 Answer 1


There are things you can't do with umask alone:

  • create a regular file with permissions above 0666.

  • create a directory with permissons above 0777.

So you do need chmod or --mode as well. If, for security reasons, you never want to create an object with temporarily higher rights than intended, chmod without umask isn't enough either. In some corner cases you have to use even both resulting in the rather ugly sequence umask / mkdir / chmod / umask. (Example: create a group temp directory (01770).)

So --mode can be replaced with chmod and umask, but not with only one of them.

  • Nitpick: I understand the value of a chmod command, since that lets you change the mode of existing things.
    – mtraceur
    Sep 9, 2015 at 18:24
  • @mtraceur You're right. I was thinking to complicated at that point. Sep 9, 2015 at 18:29
  • I don't think this is inherently a justification of dedicated -m options, however: I can see the argument for needing a way to limit permissions in the same atomic operation as file/directory/fifo/etc creation, but not so much for increasing them in the same atomic operation.
    – mtraceur
    Sep 9, 2015 at 18:31
  • The alternative to the -m option is the sequence ulimit / mkdir / chmod / ulimit. If you want a minimalistic system, you can through away the -m option, but not chmod. Sep 9, 2015 at 18:40
  • I presume you meant umask as opposed to ulimit, but anyway, I've accepted your answer because, along with the comments, it basically answers my question (or at least, it confirms my original thinking that it is in fact not strictly speaking necessary to have a -m option, but that you /do/ need chmod as well, which I forgot to mention in my original question). I would recommend adding your last comment (or a paraphrasing, doesn't really matter) into the body of your answer, as I think it's rather valuable.
    – mtraceur
    Sep 9, 2015 at 20:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .