Default Permissions and umask

Part I · Module 5 · Chapter 5.6 · Default Permissions and umask

1. Somebody Chose 644

$ touch notes.txt
$ mkdir reports

$ ls -l notes.txt
-rw-r--r-- 1 engineer engineer 0 Mar 26 14:02 notes.txt

$ ls -ld reports
drwxr-xr-x 2 engineer engineer 4096 Mar 26 14:02 reports

644 for the file, 755 for the directory. You did not ask for either, touch and mkdir did not ask you, and the same two numbers come out every time.

They are not built into the commands. They are the result of a subtraction, and the number being subtracted is yours to change.

$ umask
0022

That is the umask — short for user mask. It is a property of your shell process, inherited by everything your shell starts, and it decides the permissions on everything you create.

2. It Works Backwards

Here is the inversion that makes umask confusing, stated plainly before anything else:

chmod says which permissions to grant. umask says which permissions to withhold.

A umask of 022 does not mean "give 022". It means "never grant the permissions that 022 names" — and 022 in Chapter 5.2's arithmetic is -w- for the group and -w- for everyone else. So: do not give group write, do not give other write.

Everything else about umask follows from holding that inversion steady.

3. What It Subtracts From

The second half of the rule, and the one that is usually left out.

When something is created, the system starts from a base mode and removes whatever the umask names. The base differs between files and directories:

The file base is 666, not 777. No execute bit is ever granted automatically to a new file, no matter what the umask says. A directory gets x in its base because Chapter 5.2 established that a directory without x is nearly useless.

That is a deliberate safety property, and you can demonstrate it by removing the mask entirely:

$ ( umask 000; touch wide.txt; mkdir wide_dir; )

$ ls -l wide.txt
-rw-rw-rw- 1 engineer engineer 0 Mar 26 14:10 wide.txt

$ ls -ld wide_dir
drwxrwxrwx 2 engineer engineer 4096 Mar 26 14:10 wide_dir

With a umask of 000 — withholding nothing — the file is 666 and the directory is 777. Even granting everything possible, the file is still not executable. Creating a file can never accidentally create a program, which is exactly why Chapter 5.5 needs an explicit chmod u+x.

4. The Arithmetic

Put the two halves together:

base for a file          666      rw- rw- rw-
umask                  − 022      --- -w- -w-
                         ───
result                   644      rw- r-- r--

base for a directory     777      rwx rwx rwx
umask                  − 022      --- -w- -w-
                         ───
result                   755      rwx r-x r-x

Which is exactly what §1 produced.

5. The Three Values Worth Knowing

$ ( umask 022; touch a.txt; mkdir a_dir; )
-rw-r--r--   a.txt
drwxr-xr-x   a_dir

$ ( umask 002; touch b.txt; mkdir b_dir; )
-rw-rw-r--   b.txt
drwxrwxr-x   b_dir

$ ( umask 077; touch c.txt; mkdir c_dir; )
-rw-------   c.txt
drwx------   c_dir

Each one is a policy decision:

022 suits a personal machine and a general-purpose account. Your work is visible and nobody else can modify it.

002 is the shared-project setting, and it is the missing piece from Chapter 5.4. That chapter set a directory's group, made it group-writable, and set g+s so new files inherit the group — and then found that engineer still could not edit priya's file, because the file itself was created 644. With a umask of 002, it is created 664, and the group can write. The arrangement finally works.

077 suits anything sensitive. Nothing you create is readable by anybody else, including members of your groups.

6. Setting It

$ umask
0022

$ umask 002

$ umask
0002

$ touch shared.txt
$ ls -l shared.txt
-rw-rw-r-- 1 engineer design 0 Mar 26 14:30 shared.txt

Two things to notice.

It only affects things created afterwards. Files that already exist keep their permissions; umask is not retroactive, and fixing an existing directory means chmod per Chapter 5.3.

It applies to your shell and everything your shell starts. Chapter 1.7's rule about a child receiving a copy of its parent's state — the umask is part of that state. A job you launch creates its output files using the umask that was in effect when you launched it.

The symbolic form exists too, and reads more clearly for one-off use:

$ umask u=rwx,g=rwx,o=rx

That states what is allowed rather than what is withheld — the inverse of the numeric form, confusingly — so the numeric form is what you will see in practice.

7. The Answer to chmod +x

Chapter 5.3 and Chapter 5.5 both flagged this and deferred it. Here it is.

$ ( umask 077; touch a.sh; chmod +x a.sh; ls -l a.sh )
-rwx------ 1 engineer engineer 0 Mar 26 14:40 a.sh

$ ( umask 022; touch b.sh; chmod +x b.sh; ls -l b.sh )
-rwxr-xr-x 1 engineer engineer 0 Mar 26 14:40 b.sh

The same chmod +x produced different results, because a bare +x with no u, g or o in front of it is interpreted against the umask. It means "add execute wherever the umask would allow it".

With 022, group and other execute are not withheld, so all three get it. With 077, everything but the owner is withheld, so only the owner does.

The practical rule, now explained rather than asserted:

Say who you mean, and the umask stops being able to surprise you.

8. The Failures

Expecting umask to change existing files. It does not. New files only; chmod for the rest.

Setting it and wondering why a job's output is still wrong. The umask in effect is the one the creating process had. A long-running job started before you changed yours is still using the old value, and so is anything launched from another terminal.

Using chmod 777 to fix what a umask would fix properly. Chapter 5.3's point: if every file you create comes out with the wrong permissions, the problem is the default, not each individual file. Fixing a hundred files one at a time is a symptom of not having changed the default.

Setting it too permissively. A umask of 000 makes everything you create writable by everybody on the machine. It is occasionally suggested as a quick fix and has the same problems as chmod 777 in Chapter 5.3, applied continuously to everything you make from then on.

Forgetting it is inherited. A script that creates files inherits your umask unless it sets its own. If a flow must produce group-writable output regardless of who runs it, saying so explicitly at the top of the script is the reliable approach — Module 20.

9. Why This Matters in Engineering Work

It is the right fix for "nobody else can read my results". The wrong fix is chmod on each run's output, forever. The right one is a umask that produces readable output in the first place, at which point the problem stops recurring.

It completes the shared-directory arrangement. Chapter 5.4's three settings plus a umask of 002 is the full recipe:

chgrp design /projects/alu      the directory belongs to the team
chmod g+w    /projects/alu      the team can create entries
chmod g+s    /projects/alu      new files inherit the team's group
umask 002                       new files are group-writable

Four settings, each fixing what the previous one leaves behind. Any three of them produce a shared area that half-works, which is the state most teams end up in.

Shared machines are often configured for it already. On a well-run engineering system the default umask may be 002 precisely because group collaboration is the normal case. umask with no argument tells you what you have inherited, and is worth checking once on any machine you are new to — alongside Chapter 1.4's pwd, whoami and hostname.

10. Practice

Question 1. What does a umask of 022 withhold? Name the permissions, not just the digits.

Question 2. Give the base mode for a new file and for a new directory, and explain why they differ.

Question 3. Work out, showing the arithmetic, the file and directory permissions produced by a umask of 027.

Question 4. With a umask of 000, a new file is rw-rw-rw- and not rwxrwxrwx. Explain why, and why this is a useful property.

Question 5. Which umask value would you set for a shared project area, and what does it produce for files and for directories?

Question 6. You change your umask and an existing file keeps its old permissions. Is this a fault? What would you use instead?

Question 7. Explain why chmod +x gave -rwx------ on one machine and -rwxr-xr-x on another, and give the two forms that avoid the ambiguity.

Question 8. Chapter 5.4 set a shared directory's group, made it group-writable and set g+s, and colleagues still could not edit each other's files. Name the missing setting and explain exactly what it changes.

Question 9. A colleague fixes their output permissions with chmod after every run. What should they do instead, and why is the repeated chmod a symptom?

11. Remember

• The umask decides the permissions of everything you create. It is a property of your shell, inherited by every process it starts.
• It works backwards from chmod: it names the permissions to withhold, not the ones to grant.
• The base is 666 for files and 777 for directories. The umask is removed from that base.
• No new file is ever executable, even with a umask of 000, because the file base has no execute bit. That is why Chapter 5.5 needs an explicit chmod u+x.
• 022 gives 644 and 755 — the usual default. 002 gives 664 and 775 — the shared-work setting. 077 gives 600 and 700 — private.
• Subtraction is the right intuition; strictly the system removes bits, and the two agree for every value you will use.
• It is not retroactive. Existing files keep what they have; chmod fixes those.
• chmod +x is interpreted against the umask, which is why it is unpredictable. u+x and a+x are not.
• 002 is the fourth setting a shared directory needs, alongside the group, group write and g+s from Chapter 5.4.
• Check it on an unfamiliar machine, with umask and no argument — it tells you what your work will come out as.
• On shared storage it decides whether anyone else can read your results. Chapter 22.6 §5 measures the failure: umask 077 makes a successful run's output unusable.

That completes Module 5. You can now say who the system thinks you are and which of three categories applies to you for any file; read and write a permission string in both notations; explain what read, write and execute mean on a directory, including why a read-only file can still be deleted; change permissions deliberately rather than reaching for 777; set up a directory a team can genuinely share; make a script runnable and diagnose each of the three gates by its error message; and control what everything you create starts out as. Module 6 takes the last piece of the file model apart — the difference between a file and its name, why a directory's link count is what it is, and the two kinds of link that let one piece of data answer to more than one path.