Umask File Permissions: A Crash Course
| technology | system admin - David Zomaya

Umask File Permissions: A Crash Course

Understanding umask and default file permissions is an important part of passing certification exams like CompTIA Linux+. As you might expect, they're also important to real-world Linux security and administration.

Default permissions and umask are so important because of their effects on the security of a system. For example, with multi-user systems, default file permissions will have a major impact on who can read, edit, and execute. Similarly, locking down files created by root may be useful to make privilege escalation hacks more difficult. You also may need files created by a web server like Apache or nginx to have a specific set of permissions — and umask can help with that.

In short, it's easy to see why umask is important. It's not quite as easy to understand how it works. Here, we'll explore what umask is, how it works, and provide you with some example commands.

Before diving into the world of umask we recommend reading up on file permissions, chmod, and chown. If you're already comfortable with chmod and chown, let's dive right in!

Linux File Permissions: What is Umask?

Umask is important to Linux administration because it defines what the default permissions will be when files and directories are created.

More specifically, umask is the command that sets and displays the file mode creation mask on *nix systems. The file mode creation mask defines the default file permissions when a user creates a file. Often the term umask is used to refer to both the command and the file mode creation mask itself.

To determine the permissions on a file or directory, the file mode creation mask (a.k.a. umask) is compared to the default creation permissions. On most *nix systems, the default creation permissions are 666 (you wouldn't want everything to be executable by default!) for files and 777 for directories.

Octal, Binary, and Symbolic Representation of Permissions: A Crash Course

Before we look at how the umask and default permissions are used together, lets quickly review the symbolic, binary, and octal representations of file *nix permissions.

PermissionSymbolic valueBinary valueOctal value
No permission0000
Execute only–x0011
Write only-w-0102
Write and execute-wx0113
Read onlyr–1004
Read and executer-x1015
Read and writerw-1106
Read, write, and executerwx1117

As you may recall from our chown and chmod deep dive, file permissions in Linux systems are applied based on the user that owns the file/directory, the group that owns the file/directory, and everyone else. For example, permissions of 777 mean read, write, and execute for everyone. 640 means the user that owns the file can read and write to it, the group that owns the file can read it. Everyone else has no permissions.

How Umask Works

With an understanding of the octal representation of Linux file permissions, we can move on to how default creation permissions and umask values work together. We already know 666 files and 777 directories are the default creation permissions. Often, the default bitmask on Linux systems is 0022. In the cases it's not, it's often 0002. The leading zero is a more advanced topic, so we can set that aside for now. That leaves us with 022.

A common misconception is that the final file permissions can be determined by subtracting the umask from the default file permissions.  In some cases, that works out fine, which is probably why the misconception exists.

For example, it is true that with default file permissions of 666 and a umask of 022, the resulting permissions are 644. However, you end up with negative numbers if your umask has a 7. Additionally, as we'll demonstrate below, a umask of 333 would leave us with file permissions of 444!

How umask actually works is: when files/directories are created, a bitwise AND comparison between the umask's binary complement (the bits not set) and the default file permissions determine permissions. Another way to look at it is: the umask bits are like off switches. In binary, the umask bits that are 1, set the corresponding file permission bits to 0.

Umask Permissions at a Glance

Let's walk through an example using the default file permissions of 666 and umask of 022. Represented in binary, 6 is 110. Therefore our 666 permissions are 110 110 110. 2 in binary is 010, which means our 022 mask is 010 010 010.

Now we can just line the bits up and compare. Here is the logic:

  • If there is a 0 in the umask bit, nothing changes from the defaults.
  • If there is a 1 in the umask and a 1 in the default permissions, we change it to a 0.
  • If there is a 1 in the umask bit and a 0 in the default permissions, the resulting permission is 0.
OwnerGroupEveryone Else
Read BitWrite BitExecute BitRead BitWrite BitExecute BitRead BitWrite BitExecute Bit
Default file permissions (666)110110110
umask (022)000010010
Resulting permissions110100100

110 100 100 means our resulting permissions are 644 or rw-r–r–

Now, let's try with the default directory permissions of 777 and a umask of 022. With 777, all our binary bits are set to 1.

OwnerGroupEveryone Else
Read BitWrite BitExecute BitRead BitWrite BitExecute BitRead BitWrite BitExecute Bit
Default directory permissions (777)111111111
umask (022)000010010
Resulting permissions111101101

111 111 111 means our resulting permissions are 755 or rwxr-xr-x.

Remember: while it may seem odd to have "execute" permissions on a directory, there is a reason! Execute permissions are required to enter a directory and access its contents.

So far, our examples would work if we just subtracted. After all, 666 – 022 = 644 and 777 – 022 = 755. Let's take a look at two examples where subtraction falls apart.

Here we can see that default file permissions of 666 and a umask of 333 leave us with octal permissions of 444 (owner, group, and everyone else have read-only permissions). This is because 3 in binary is 011, which means the umask will turn off the "write" and "execute" bits.

OwnerGroupEveryone Else
Read BitWrite BitExecute BitRead BitWrite BitExecute BitRead BitWrite BitExecute Bit
Default File permissions (666)110110110
umask (333)011011011
Resulting permissions100100100

In the case of the default file permissions of 666 and a umask of 777, we'd end up with negative numbers if we just subtracted. What we actually get is all zeros. This makes perfect sense when you think of the umask as an off switch.

OwnerGroupEveryone Else
Read BitWrite BitExecute BitRead BitWrite BitExecute BitRead BitWrite BitExecute Bit
Default File permissions (666)110110110
umask (777)111111111
Resulting permissions000000000

Umask Commands at a Glance

Now that we understand how umask works, let's look at some example commands. We're specifically using Ubuntu 20.04 to create these examples, but commands should be mostly consistent across different Linux operating systems.

Show the current umask in octal format

To show the current umask in octal format, simply type umask with no switches or options.

cooluser@LAPTOP-5V55HON5:~$ umask
0022
cooluser@LAPTOP-5V55HON5:~$

Show the current umask in symbolic format

To see the umask symbolically, add the -S switch to umask.

cooluser@LAPTOP-5V55HON5:~$ umask -S
u=rwx,g=rx,o=rx
cooluser@LAPTOP-5V55HON5:~$

Note that the symbolic representation of umask shows the maximum file permissions a file/directory could have given the current umask. For example, even though the above output shows the execute permission for user, group, and everyone else, we know from our earlier examples the execute bit won't be set. This is because the default file permissions are 666 (or rw-rw-rw).

Change the current umask using octal values

Changing the umask for your current session is achieved with the command umask . For example, to change the umask to 027 (which is a bit more secure than 022), we can use umask 027

cooluser@LAPTOP-5V55HON5:~$ umask 027
cooluser@LAPTOP-5V55HON5:~$ umask
0027
cooluser@LAPTOP-5V55HON5:~$

Change the current umask using symbolic values

Like with octal values, you can add symbolic values after the umask command to change the umask for your current session. When using symbolic values, here are important characters to know:

  • u – the user that owns the file/directory
  • g – the file's/directory's group
  • o – everyone else
  • r – read permission
  • w – write permission
  • x – execute permission

You simply combine the u, g, and o values with the corresponding r, w, x permissions that you want the mask to allow. For example, to allow read, write, and execute for the file's user, read and write for the group, and read for everyone else, use umask u=rwx,g=rw,o=r.

cooluser@LAPTOP-5V55HON5:~$ umask u=rwx,g=rw,o=r
cooluser@LAPTOP-5V55HON5:~$ umask
0013
cooluser@LAPTOP-5V55HON5:~$ umask -S
u=rwx,g=rw,o=r
cooluser@LAPTOP-5V55HON5:~$

Setting the umask value permanently

You may have noticed that the commands above set the umask for your current session. The changes won't persist across reboots or logouts. There are multiple different ways to change the umask permanently, which can lead to confusion across different distributions.

For example, sometimes pam_umask and editing /etc/login.defs may work. However, systems that use systemd work differently with pam_umask than other Linux versions. This has caused plenty of confusion and complaints in the open source community, and the related bug report and documentation issue were just closed earlier this year.

In other cases, an edit of /etc/default/login may be the answer. Another approach is to set permanent umask values for a user in ~/.profile or ~/.bashrc. There are also options to set umask_override in the  sudoers file when sudo is invoked.

Final Thoughts: Using Umask Wisely

There's plenty of debate around which umask value is best. Some have argued for a default of 002 while others prefer 022, 027, or 077 for root in particular. Like most things, there is a security vs. usability tradeoff. The important thing is that you understand how umask works, how that impacts file access, and what's best for your environment.

Download

Download

Ultimate Systems Administration Cert Guide

A 158-page guide to every Microsoft, VMware, Citrix, AWS, Google, and Linux certification, and how they fit into your career.

By submitting this form you agree that you have read, understood, and are able to consent to our privacy policy.

LEARNING ON MOBILE

Learn anytime anywhere with our mobile apps.

I have read and understood the privacy policy and am able to consent to it.

© 2021 CBT Nuggets. All rights reserved. Terms | Privacy Policy | Accessibility | Sitemap | 1550 Valley River Drive, Eugene, OR 97401 | 541-284-5522
CBT Nuggets