As I've found out, when using umask, the highest permissions you can give to files are 666. Which is done by umask 0000. That's because of the default file creation permissions, which appear to be 666 on every system that I know.

I know for files we need executable rights to show their contents.
But why do we limit the default file creation permissions on 666?

  • What kind of system? The only umask I met was always 0022, creating default permission 644. – manatwork Nov 21 '13 at 12:43
  • No you misunderstood. Umask is using the default file permissions of 666 and substracts its own value (which is 0022 for your system). So the most permissions you could set is umask 0000 - which still limits to file permissions of 666. (But apparently folders use 777) – Peter Nov 21 '13 at 12:45
  • Got you. Now this is a good question. – manatwork Nov 21 '13 at 12:49
  • 2
    You don't need executable permissions to see file contents. This is so for directories which is why directories are created by default with execute permissions. – Joseph R. Nov 21 '13 at 12:50
  • 1
    I believe [but would need to look more to be sure] that this is by design, to avoid some security problems: without access to "chmod", you can't make a file executable. umask 0000 creates files with 0666 and directories with 0777 [which, by the way, is quite an awful default setting, security wise!] – Olivier Dulac Nov 21 '13 at 17:19

As far as I can tell, this is hard-coded into standard utilities. I straced both a touch creating a new file and a mkdir creating a new directory.

The touch trace produced this:

open("newfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3

while the mkdir trace produced this:

mkdir("newdir", 0777)                   = 0

Short of coding the file/directory creation process in C, I don't see a way of modifying the default permissions. It seems to me, though, that not making files executable by default makes sense: you don't want any random text to be accidentally misconstrued as shell commands.


To give you an example of how the permission bits are hard-coded into the standard utilities. Here are some relevant lines from two files in the coreutils package that contains the source code for both touch(1) and mkdir(1), among others:


if (specified_mode)
     struct mode_change *change = mode_compile (specified_mode);
     if (!change)
       error (EXIT_FAILURE, 0, _("invalid mode %s"),
              quote (specified_mode));
     options.mode = mode_adjust (S_IRWXUGO, true, umask_value, change,
     free (change);
    options.mode = S_IRWXUGO & ~umask_value;

In other words, if the mode is not specified, set it to S_IRWXUGO (read: 0777) modified by the umask_value.

touch.c is even clearer:

int default_permissions =

That is, give read and write permissions to everyone (read: 0666), which will be modified by the process umask on file creation, of course.

You may be able to get around this programmatically only: i.e. while creating files from within either a C program, where you make the system calls directly or from within a language that allows you to make a low-level syscall (see for example Perl's sysopen under perldoc -f sysopen).

  • You are right, I don't want any accidents. But to have no way to change it, is awful! Standard values should be 777. And we need umask file and umask dir. Set two different default values and fine. But now I have no way to create files with exec perms. – Peter Nov 21 '13 at 13:10
  • 1
    @PeterI Well, mkdir(1) does offer you a -m switch to specify the directory's mode at creation time. With files, however, since file creation uses the open(2) syscall, the tool you use to create the file is the one that's responsible for passing the mode bits to open and you don't get a say in the matter. install(1) by default copies your file to a new location and sets the execute bits, but that's still not happening at creation time. – Joseph R. Nov 21 '13 at 13:18
  • What you are saying, that touch for example is responsible to set the right values. Do you know where it stores the values? Maybe they are set systemwide - so we could change them? Because I want to break free ;) – Peter Nov 21 '13 at 13:21
  • @PeterI See the updated answer. – Joseph R. Nov 21 '13 at 13:27
  • 1
    @PeterI I updated the answer again. You may be able to make the syscall directly from within either C or another language like Perl. – Joseph R. Nov 21 '13 at 13:32

First off, there is no global default, the permissions depend on the application that creates the file. For example, this little C program will create a file '/tmp/foo' with permissions 0777 if umask is 0000 (in any case permissions will be 0777 & ~umask):

int main() 
   creat("/tmp/foo", 0777);
   return 0;

That being said, many applications create files with permissions of 0666. That has two reasons:

  1. Security: you do not want any arbitrary file to be executable.
  2. Convenience: most files do not need to be executable. It is easier to set the executable bit on a select few files than to unset it on the huge amount of other files. Of course, umask 0133 would solve this, but then nothing is won and you couldn't let programs create executable files even if you wanted to.
  • 1
    Files are created without the x(execute) bit set for security reasons. The inadvertent execution of files [cw]ould be a "Bad Thing"(tm). The chmod program gives you ability to (re)set permissions bits as needed. – ChuckCottrill Nov 22 '13 at 0:02

protected by jasonwryan Oct 20 '15 at 0:21

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.