What does a process's umask do on Linux, and why does a umask of 022 produce new files with mode 644 but new directories with 755?

## A mask, not a default The single most common misunderstanding is that the umask *sets* the permissions of new files. It does the opposite: it names the bits that must **not** appear. When a program creates a file it supplies a mode argument, and the kernel computes ``` final_mode = requested_mode & ~umask ``` Read literally: take the requested bits, and clear every bit that is set in the mask. People often describe it as subtraction because `666 - 022 = 644` happens to come out right, but that is a coincidence of the common values. With a umask of `023`, subtraction would suggest `643`; the actual result is `0666 & ~0023 = 0644`, because bit-clearing cannot remove a bit that was not there. Reason with AND-NOT, never with arithmetic. ## Where the asymmetry comes from Why do files come out `644` and directories `755` under the same mask? - Library and shell routines that create a plain file conventionally request `0666` — read and write for everyone, and **no execute for anyone**. - `mkdir` requests `0777`, because a directory without its execute bit is unusable: you could not traverse into it. The mask then does the same thing to both: ``` files: 0666 & ~0022 = 0644 -> rw-r--r-- directories: 0777 & ~0022 = 0755 -> rwxr-xr-x ``` So the execute difference is entirely in the request. This also explains why you cannot make new files executable by choosing a clever umask: the mask has no power to add a bit that the caller never asked for. ## Scope and inheritance The umask is per-process state, like the current working directory. A child inherits it across `fork()` and it survives `exec()`, which is why setting it in a shell affects every command you subsequently run from that shell — and why setting it inside a script does not leak back to the parent shell. You read and set it with the shell builtin: ``` $ umask # 0022 $ umask -S # u=rwx,g=rx,o=rx (symbolic: what is ALLOWED) $ umask 027 # clear group-write, and all three bits for others ``` Note the inversion in the symbolic form: `umask` with no argument prints the bits being **removed**, while `umask -S` prints the bits that survive. Mixing those two readings up is a classic source of confusion. A login session's initial value comes from the login stack — commonly `/etc/profile` and shell startup files, or the `UMASK` setting in `/etc/login.defs` applied by the PAM module that handles it. Typical values: - `022` — the traditional default; new files are world-readable. - `027` — group-readable, nothing for others; common on shared servers. - `002` — group-writable, used on distributions that give every user a private group of their own, so "group-writable" is harmless for personal files but makes shared project directories work. - `077` — private to the owner; appropriate for accounts that handle sensitive material. ## What the umask does not touch - **`chmod`.** An explicit mode change is exactly that; the mask is not consulted. - **Existing files.** Changing the umask has no retroactive effect whatsoever. - **Restored modes.** `cp -p`, `rsync -p` and `tar -p` reapply a mode recorded elsewhere rather than creating with a default request, so the mask does not filter them. - **Programs that request a tight mode deliberately.** Something creating a private key file typically requests `0600`; the mask can only make that *tighter*, never looser. This is the right pattern — security-sensitive code should never rely on the caller's mask to protect it. ## Where it bites in production Two failure shapes recur. First, a daemon that inherits a `077` umask from an unusual login environment writes files nothing else can read, and the failure surfaces far downstream in whatever tries to consume them. Second, a shared upload or spool directory where several accounts must edit each other's files: with `022`, everything lands group-read-only and collaboration breaks. The umask is one half of that fix; the group ownership of the directory is the other half, and both need to be right. When you need a specific mask for a service, set it where the service is actually started rather than in an interactive shell file, because an interactive shell's startup files are not read for a daemon. ## The interview answer in one line It is a per-process mask of bits to clear at creation time, applied as `requested & ~umask`; files come out `644` and directories `755` under `022` because the creators request `0666` and `0777`, and the mask can only ever subtract.