umask(2)

💅 umask — set file mode creation mask

okay bestie, welcome to umask(2) — a manual page from the System Calls Manual section, and honestly? she's a little icon. let's get into it 🎀

---

✨ NAME ✨

umask — set file mode creation mask

📚 LIBRARY 📚

Standard C library (libc, -lc) 🫶

🌸 SYNOPSIS 🌸

#include <sys/stat.h>

mode_t umask(mode_t mask);

💖 DESCRIPTION 💖

so like, umask() sets the calling process's file mode creation mask (aka the umask, duh) to mask & 0777 — and the tea is that only the file permission bits of mask are used — and then it hands you back the previous value of the mask. retro vibes, she's giving nostalgia ✨

okay so what's the mask even for? the umask is used by open(2), mkdir(2), and other system calls that create files, to modify the permissions placed on newly created files or directories. specifically: permissions in the umask are turned off from the mode argument to open(2) and mkdir(2). it's literally just subtraction energy. bestie she's a filter 💅

but wait — plot twist 🍓 — alternatively, if the parent directory has a default ACL (see acl(5)), then:

• the umask is ignored (not me getting ghosted 😭)
• the default ACL is inherited
• the permission bits are set based on the inherited ACL
• and permission bits absent in the mode argument are turned off

for example, the following default ACL is equivalent to a umask of 022:

u::rwx,g::r-x,o::r-x

and if you combine the effect of this default ACL with a mode argument of 0666 (rw-rw-rw-), the resulting file permissions would be 0644 (rw-r--r--). math ate, no cap 🧮👑

the constants that should be used to specify mask are described in inode(7).

the typical default value for the process umask is S_IWGRP | S_IWOTH (octal 022). in the usual case where the mode argument to open(2) is specified as:

S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH

(octal 0666) when creating a new file, the permissions on the resulting file will be:

S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH

(because 0666 & ~022 = 0644; i.e., rw-r--r--). see how the write bits for group and other just... vanished? main character behavior of the mask honestly 🌈

🎀 RETURN VALUE 🎀

this system call always succeeds and the previous value of the mask is returned. no error codes, no drama, no cliffhanger. she simply slays 💅

📜 STANDARDS 📜

POSIX.1-2008.

🦋 HISTORY 🦋

POSIX.1-2001, SVr4, 4.3BSD. a certified classic, older than your fave ⭐

💜 NOTES 💜

• a child process created via fork(2) inherits its parent's umask. family business ✨
• the umask is left unchanged by execve(2). she does not switch up on you.
• it is impossible to use umask() to fetch a process's umask without at the same time changing it. a second call to umask() would then be needed to restore the umask. and bestie, the nonatomicity of these two steps provides the potential for races in multithreaded programs — so yes, this is the dangerous part, be careful fr fr 😭💀
• since Linux 4.7, the umask of any process can be viewed via the Umask field of /proc/pid/status. inspecting this field in /proc/self/status allows a process to retrieve its umask without at the same time changing it. that's the hack, iykyk 🫶
• the umask setting also affects the permissions assigned to POSIX IPC objects (mq_open(3), sem_open(3), shm_open(3)), FIFOs (mkfifo(3)), and UNIX domain sockets (unix(7)) created by the process.
• but ngl, the umask does not affect the permissions assigned to System V IPC objects created by the process (using msgget(2), semget(2), shmget(2)). she said not my department 🙈

👑 SEE ALSO 👑

chmod(2), mkdir(2), open(2), stat(2), acl(5)

---

and that's the whole page, bestie! 💖 this one's from Linux man-pages 6.20, dated 2026-02-08 — go forth and set those masks responsibly, ily 🧚✨