< Previous | Contents | Next >

umask – Set Default Permissions

The umask command controls the default permissions given to a file when it is created. It uses octal notation to express a mask of bits to be removed from a file's mode at- tributes. Let's take a look:

[me@linuxbox ~]$ rm -f foo.txt

[me@linuxbox ~]$ umask

0002

[me@linuxbox ~]$ > foo.txt

[me@linuxbox ~]$ rm -f foo.txt

[me@linuxbox ~]$ umask

0002

[me@linuxbox ~]$ > foo.txt

[me@linuxbox ~]$ ls -l foo.txt

-rw-rw-r-- 1 me me 0 2016-03-06 14:53 foo.txt

[me@linuxbox ~]$ ls -l foo.txt

-rw-rw-r-- 1 me me 0 2016-03-06 14:53 foo.txt

We first removed any old copy of foo.txt to make sure we were starting fresh. Next, we ran the umask command without an argument to see the current value. It responded with the value 0002 (the value 0022 is another common default value), which is the oc- tal representation of our mask. We next create a new instance of the file foo.txt and observe its permissions.

We can see that both the owner and group get read and write permission, while everyone else only gets read permission. The reason that world does not have write permission is because of the value of the mask. Let's repeat our example, this time setting the mask our- selves:

[me@linuxbox ~]$ rm foo.txt [me@linuxbox ~]$ umask 0000 [me@linuxbox ~]$ > foo.txt [me@linuxbox ~]$ ls -l foo.txt

-rw-rw-rw- 1 me me 0 2016-03-06 14:58 foo.txt

[me@linuxbox ~]$ rm foo.txt [me@linuxbox ~]$ umask 0000 [me@linuxbox ~]$ > foo.txt [me@linuxbox ~]$ ls -l foo.txt

-rw-rw-rw- 1 me me 0 2016-03-06 14:58 foo.txt

When we set the mask to 0000 (effectively turning it off), we see that the file is now world writable. To understand how this works, we have to look at octal numbers again. If we take the mask and expand it into binary, and then compare it to the attributes we can see what happens:

Ignore for the moment the leading zeros (we'll get to those in a minute) and observe that where the 1 appears in our mask, an attribute was removed — in this case, the world write permission. That's what the mask does. Everywhere a 1 appears in the binary value of the mask, an attribute is unset. If we look at a mask value of 0022, we can see what it does:

Again, where a 1 appears in the binary value, the corresponding attribute is unset. Play with some values (try some sevens) to get used to how this works. When you're done, re- member to clean up:

[me@linuxbox ~]$ rm foo.txt; umask 0002

[me@linuxbox ~]$ rm foo.txt; umask 0002

Most of the time we won't have to change the mask; the default provided by your distri- bution will be fine. In some high-security situations, however, we will want to control it.

Some Special Permissions

Though we usually see an octal permission mask expressed as a three digit num- ber, it is more technically correct to express it in four digits. Why? Because, in ad- dition to read, write, and execute permission, there are some other, less used, per- mission settings.

The first of these is the setuid bit (octal 4000). When applied to an executable file, it sets the effective user ID from that of the real user (the user actually running the program) to that of the program's owner. Most often this is given to a few pro- grams owned by the superuser. When an ordinary user runs a program that is “se- tuid root” , the program runs with the effective privileges of the superuser. This allows the program to access files and directories that an ordinary user would nor- mally be prohibited from accessing. Clearly, because this raises security concerns, the number of setuid programs must be held to an absolute minimum.

The second less-used setting is the setgid bit (octal 2000) which, like the setuid bit, changes the effective group ID from the real group ID of the real user to that of the file owner. If the setgid bit is set on a directory, newly created files in the directory will be given the group ownership of the directory rather the group own- ership of the file's creator. This is useful in a shared directory when members of a common group need access to all the files in the directory, regardless of the file owner's primary group.

The third is called the sticky bit (octal 1000). This is a holdover from ancient Unix, where it was possible to mark an executable file as “not swappable.” On files, Linux ignores the sticky bit, but if applied to a directory, it prevents users from deleting or renaming files unless the user is either the owner of the directory, the owner of the file, or the superuser. This is often used to control access to a shared directory, such as /tmp.

Here are some examples of using chmod with symbolic notation to set these spe- cial permissions. First assigning setuid to a program:

chmod u+s program

Next, assigning setgid to a directory:

chmod g+s dir

Finally, assigning the sticky bit to a directory:

chmod +t dir

When viewing the output from ls, you can determine the special permissions. Here are some examples. First, a program that is setuid:

-rwsr-xr-x

A directory that has the setgid attribute:

drwxrwsr-x

A directory with the sticky bit set:

drwxrwxrwt

< Previous | Contents | Next >