Linux umask Cheat Sheet: 022 vs 027 vs 077 Explained

Linux umask Command Cheat Sheet: Set Secure Default File Permissions (022, 027, 077 Explained)

Quick Answer
The umask command controls which permissions are removed from newly created files and directories. Use 027 for most servers, 077 for private data, and 022 only when others must read files.

Picture a routine incident review. A nightly backup job runs under cron and writes database dumps into a shared directory. Nobody ever ran chmod on those files, yet any local user on the box can read them. No exploit was involved. The job simply inherited a permissive default umask. (This is an illustrative scenario, but variations of it show up regularly in audits.)

That is why umask matters for Linux server hardening. It is a small setting that quietly decides whether every new log, key, export, and config file starts out private or exposed. This guide covers the commands, the math, and how to audit and enforce a safe default across a fleet.

Table of Contents

• How umask actually works
• Common umask values compared
• Viewing and setting umask
• Testing the resulting permissions
• Using subshells and saving umask safely
• Symbolic umask notation
• Making umask persistent and auditing it
• umask and CIS benchmark compliance
• Detection: finding exposed files
• Expert tips and common mistakes
• FAQ

How umask actually works

The umask is a mask of permission bits that gets subtracted from the maximum permissions a program requests when it creates something. Two base values matter:

• Regular files start from 666 (read and write, no execute)
• Directories start from 777 (read, write, and execute)

Files start without the execute bit on purpose, so a new text file never becomes executable by accident. With umask 022, a file becomes 644 and a directory becomes 755. Strictly speaking, the kernel clears the masked bits (it does not do arithmetic subtraction), which is why the result is the same as subtraction for these common cases but can surprise you with unusual masks.

Two important caveats:

• umask only affects permissions at creation time. It never changes existing files, and chmod ignores it.
• The program creating the file can request fewer permissions than 666 or 777. SSH private keys, for example, are typically created with stricter modes regardless of your umask.

Common umask values compared

umask	New files	New directories	Typical use
022	644	755	General default; others can read
027	640	750	Common server baseline; others locked out
077	600	700	Private user data, secrets, admin accounts
002	664	775	Shared workgroups with group write
000	666	777	Not recommended; world-writable by default

Umask 000 is the dangerous one. Every new file becomes writable by every local user, which opens the door to tampering and privilege escalation chains when combined with scripts or services that trust those files.

Viewing and setting umask

Check the current value first so you know what you are working with.

umask

This prints the mask for the current shell, for example 0022. The leading zero is the special-bits position and is normally ignored.

umask -S

This prints the same mask in symbolic form, such as u=rwx,g=rx,o=rx. Note that the symbolic form shows what is allowed, not what is masked.

Set the common values for the current shell session:

umask 022   # files 644, directories 755
umask 027   # files 640, directories 750
umask 077   # files 600, directories 700
umask 002   # files 664, directories 775 (shared group work)

These changes last only for the current shell and its child processes. Opening a new terminal returns you to the system default.

Testing the resulting permissions

Never assume the math. Create a throwaway file and directory and look at them.

umask 022; touch file.txt; mkdir testdir; ls -l file.txt; ls -ld testdir

Expected output shows -rw-r--r-- for the file and drwxr-xr-x for the directory.

For numeric output that is easy to paste into a ticket or audit note, use stat:

umask 077; touch secret.txt; stat -c "%a %n" secret.txt
umask 077; mkdir private; stat -c "%a %n" private

You should see 600 secret.txt and 700 private. Create several files at once with touch file1 file2 file3, or a nested tree with mkdir -p project/logs. Every item created under the active umask follows the same rule.

Using subshells and saving umask safely

In real operations you rarely want to change the umask for your whole session. Two clean patterns avoid that.

Pattern 1: a subshell. Parentheses run the commands in a child shell, so the parent's umask is untouched.

(umask 077; touch secret.txt; mkdir secret_dir)

Use this when generating a single sensitive artifact, such as an export or a temporary credentials file. Afterward, run umask in your normal shell and confirm it did not change.

Pattern 2: save and restore. Useful inside longer scripts.

OLD_UMASK=$(umask)
umask 077
# ... create sensitive files here ...
umask "$OLD_UMASK"

One caution: if the script exits early, the restore line never runs. In scripts that matter, prefer the subshell pattern or a trap to restore the value.

Symbolic umask notation

Symbolic notation lets you state what each class keeps rather than what it loses.

umask u=rwx,g=rx,o=

This is equivalent to 027: the owner keeps everything, the group keeps read and execute, and others keep nothing.

umask u=rwx,g=,o=

This is equivalent to 077. Verify either one with umask -S. Many admins find the numeric form faster, but symbolic output is clearer when reviewing someone else's configuration.

Making umask persistent and auditing it

Interactive changes vanish at logout. To see where a system actually sets its default, search the common configuration locations:

grep -R "umask" /etc/profile /etc/bash.bashrc /etc/login.defs 2>/dev/null

This lists any umask setting in system-wide shell and login configuration. Then check the individual user's startup files:

grep -n "umask" ~/.bashrc ~/.profile 2>/dev/null

Which files apply depends on the distribution and PAM configuration. Some systems also set umask through /etc/profile.d/ scripts or the pam_umask module, so treat the commands above as a starting point, not a complete inventory.

Services are a separate case. Daemons started by systemd do not read your shell profile. If a service creates sensitive files, check its unit for a UMask= directive. This is the most common reason a "locked-down" server still produces world-readable service output.

umask and CIS benchmark compliance

For enterprise Linux security compliance, default file permissions show up in hardening baselines. Many CIS Benchmark profiles for Linux distributions call for a default user umask of 027 or more restrictive, and auditors commonly check both the configured value and whether any startup file overrides it. Exact requirements differ by benchmark version and distribution, so confirm against the specific benchmark your organization follows rather than assuming 027 is universal.

Practical takeaway: pick 027 as your organizational baseline, document exceptions (for example 002 for a shared project directory), and make the audit repeatable.

Detection: finding exposed files from a weak umask

A good file permissions audit looks for the symptoms of a permissive umask. These read-only commands are safe to run on production hosts:

find /var/backups /srv /opt -type f -perm -0002 2>/dev/null

Lists regular files that are writable by others in the named directories. Any hit deserves an explanation.

find /var/log /var/backups -type f -perm -0004 2>/dev/null | head

Lists world-readable files in locations that often hold sensitive data. Adjust the paths to your environment, and expect noise from logs that are intentionally readable.

For SOC teams, the interesting signal is a pattern: many files created by one account or service all sharing the same overly open mode usually points to a single misconfigured umask at the source. Fix the source (shell profile, PAM, or the service's UMask= setting), then correct existing files deliberately with chmod after reviewing them. Avoid blanket recursive permission changes on production paths without a backup, because applications can depend on specific modes.

Expert tips and common mistakes

• Test before you roll out. Switching a fleet from 022 to 027 can break web servers, monitoring agents, or backup tools that run as a different user and relied on world-readable files. Pilot on a staging host first.
• Remember group membership. With 027, access works only if the right users are in the right group. Check group ownership, not only mode bits.
• Do not rely on umask alone. Pair it with correct ownership, restricted parent directories, and ACLs where needed. A 700 parent directory protects its contents even if a child file is 644.
• Use 077 for secrets. Scripts that write tokens, key material, or exports should set it locally with a subshell rather than depending on the system default.
• Shared workgroups need intent. Umask 002 is fine for a collaborative project directory, but pair it with the setgid bit on the directory so new files inherit the right group.
• Verify after changing. Run the stat test above in a fresh login session, not just the shell where you edited the file.

Related Cybersecurity Topics You Should Explore

• Linux chgrp Cheat Sheet (2026): Commands, Examples & Audit Tips
  
• Linux chown Command Cheat Sheet: 40+ Examples (2026)
  
• Linux chmod Cheat Sheet: Stop Using 777 (Safer Fixes)
  
• OnePlus 15 Root Exploit: Zero-Permission Apps Can Take Full Control
  
• One Misconfigured chmod Command Gave Attackers Root Access
  
• How SOC Analysts Use sed to Catch Attacks Before the SIEM Does
  
• Linux tr Command Tutorial: Fix Messy SOC Logs in Seconds
  
• Linux tee Command: The SOC Trick That Saves Evidence Before It's Gone
  
• Linux wc Command Tutorial: Count Log Lines Like a SOC Pro

FAQ

What does umask 022 mean?

It removes write permission for group and others. New files become 644 and new directories become 755.

What is the most secure umask?

Umask 077 is the most restrictive of the common values: only the owner can access new files (600) and directories (700). Whether it fits depends on whether other users or services must read what you create.

Does umask change permissions on existing files?

No. It applies only when new files and directories are created. Use chmod to change existing ones.

Why do new files not get execute permission even with umask 000?

Regular files start from 666, not 777, so the execute bit is never present by default. You must add it explicitly with chmod.

How do I make umask permanent?

Set it in the appropriate startup or login configuration, such as ~/.bashrc for one user or system-wide configuration for all users. The right file depends on your distribution, and services started by systemd need their own UMask= setting.

Why is a file more permissive than my umask suggests?

The creating program may set an explicit mode, tools like cp or tar can preserve source permissions, and directories with the setgid bit or default ACLs can alter the result. Always verify with stat.

Conclusion

Umask is easy to overlook because it never throws an error. It just silently shapes the permissions of everything your users and services create. Set a deliberate baseline (027 is a sensible starting point for servers), use 077 for secrets, audit the places where defaults are configured, and verify results with stat instead of trusting the arithmetic. A few minutes spent here removes a whole class of accidental data exposure.

Analysis based on SOC monitoring experience and standard Linux and POSIX documentation.