RED HAT ENTERPRISE LINUX

Default Permissions & umask

Display and Set Default File Permissions

College-Level Course Module | RHEL System Administration

Welcome to this module on default permissions and umask. When you create a new file or directory, Linux assigns it initial permissions automatically. But how does it decide what those permissions should be? The answer is umask - the user file-creation mask. Understanding umask is essential for security. If default permissions are too open, newly created files might be readable or writable by users who should not have access. If too restrictive, legitimate users might be blocked. In this module, you will learn how Linux determines default permissions for new files and directories, how to display and interpret the current umask value, how to calculate resulting permissions from umask, how to set umask temporarily and permanently, and security considerations for choosing appropriate umask values. These skills help you control file security from the moment files are created.

Learning Objectives

Review permission basics

Octal notation and permission meanings

Understand umask

What umask is and how it affects new files

Calculate permissions

Determine resulting permissions from umask values

Set umask values

Change umask temporarily and permanently

Apply security best practices

Choose appropriate umask for different scenarios

Permission Review

Linux permissions control who can read, write, and execute files and directories. Permissions are set for owner, group, and others.

Permission	Symbol	Octal	File Meaning	Directory Meaning
Read	r	4	View file contents	List directory contents
Write	w	2	Modify file contents	Create/delete files in dir
Execute	x	1	Run as program	Enter directory (cd)

[user@host ~]$ ls -l myfile.txt
-rw-r--r--. 1 user user 100 Jan 20 10:00 myfile.txt
 │├─┤├─┤├─┤
 │ │  │  └── Others: read only (4)
 │ │  └───── Group: read only (4)
 │ └──────── Owner: read + write (6)
 └────────── File type (- = regular file)

Let me quickly review Linux permissions before discussing umask. Permissions control access at three levels: owner (the file's user), group (members of the file's group), and others (everyone else). Each level can have read, write, and execute permissions. For files, read means viewing contents, write means modifying contents, and execute means running as a program. For directories, the meanings differ slightly. Read lists contents, write allows creating and deleting files within the directory, and execute allows entering the directory with cd. Permissions are represented in octal notation. Read is 4, write is 2, execute is 1. Add them for combined permissions: read plus write is 6, read plus write plus execute is 7. The ls -l output shows permissions symbolically. The example shows rw-r--r-- which means owner can read and write (6), group can read (4), others can read (4). In octal, that is 644.

Octal Permission Values

Octal	Binary	Symbolic	Permissions
0	000	---	None
1	001	--x	Execute only
2	010	-w-	Write only
3	011	-wx	Write + Execute
4	100	r--	Read only
5	101	r-x	Read + Execute
6	110	rw-	Read + Write
7	111	rwx	Read + Write + Execute

7 5 5

Owner | Group | Others

rwx r-x r-x

Symbolic notation

What is umask?

umask (user file-creation mask) is a value that determines which permissions are removed from the default permissions when creating new files and directories.

Default Permissions − umask = Actual Permissions

# Display current umask
[user@host ~]$ umask
0022

# Display in symbolic form
[user@host ~]$ umask -S
u=rwx,g=rx,o=rx

# The umask REMOVES permissions, it doesn't grant them
# umask 022 removes write for group and others

Key concept: umask specifies which permissions to take away, not which to give. A umask of 022 removes write permission from group and others.

umask stands for user file-creation mask. It is a filter that removes certain permissions from newly created files and directories. Think of it as a permission mask - it blocks (masks out) certain permissions. The relationship is: the system starts with default full permissions, then subtracts the umask to get the actual permissions. A umask of 022 means remove write (2) from group, and remove write (2) from others. The umask command with no arguments displays the current value in octal. The leading zero indicates octal notation. umask -S shows the symbolic interpretation - what permissions will be allowed after applying the mask. The output u=rwx,g=rx,o=rx means owner gets full access, group gets read and execute, others get read and execute. It is crucial to understand that umask removes permissions. A higher umask value means more restricted files, not less restricted.

Base Permissions

Before applying umask, the system starts with base permissions that differ for files and directories.

Files: 666

Base: rw-rw-rw-

Read and write for everyone.
No execute by default (security).

Directories: 777

Base: rwxrwxrwx

Full access for everyone.
Execute needed to enter directory.

Why the difference? Files do not get execute permission by default for security - a new text file should not be runnable. Directories need execute permission to allow cd.

The base permissions are the starting point before umask is applied. They differ for files and directories. For regular files, the base permission is 666 - read and write for owner, group, and others. Notice there is no execute permission. This is a security feature. When you create a text file, it should not be executable. If you want a file executable, you must explicitly add that permission with chmod. For directories, the base permission is 777 - full access for everyone including execute. Directories need execute permission for users to enter them with cd. Without execute, users could not access files inside even if they could see the listing. This base permission difference means the same umask produces different results for files versus directories. A umask of 022 applied to a file (base 666) gives 644. Applied to a directory (base 777), it gives 755.

Calculating File Permissions

For files: Start with base 666, subtract umask.

Base file permissions: 666 (rw-rw-rw-)

umask value: − 022 (----w--w-)

Resulting permissions: 644 (rw-r--r--)

# Create a file with umask 022
[user@host ~]$ umask
0022
[user@host ~]$ touch newfile.txt
[user@host ~]$ ls -l newfile.txt
-rw-r--r--. 1 user user 0 Jan 20 10:00 newfile.txt
# 644 = Owner: rw, Group: r, Others: r

Calculating Directory Permissions

For directories: Start with base 777, subtract umask.

Base directory permissions: 777 (rwxrwxrwx)

umask value: − 022 (----w--w-)

Resulting permissions: 755 (rwxr-xr-x)

# Create a directory with umask 022
[user@host ~]$ umask
0022
[user@host ~]$ mkdir newdir
[user@host ~]$ ls -ld newdir
drwxr-xr-x. 2 user user 6 Jan 20 10:00 newdir
# 755 = Owner: rwx, Group: rx, Others: rx

Common umask Values

umask	File Result	Dir Result	Use Case
022	644 (rw-r--r--)	755 (rwxr-xr-x)	Standard user default - readable by all
027	640 (rw-r-----)	750 (rwxr-x---)	Group collaboration - no others access
077	600 (rw-------)	700 (rwx------)	Private - owner only access
002	664 (rw-rw-r--)	775 (rwxrwxr-x)	Shared group - group can write
007	660 (rw-rw----)	770 (rwxrwx---)	Group only - no others
000	666 (rw-rw-rw-)	777 (rwxrwxrwx)	No restrictions (dangerous!)

RHEL defaults: Regular users get umask 0022. Root gets umask 0022. Some organizations set stricter defaults like 0027 or 0077.

Here are common umask values and their effects. 022 is the standard default on most Linux systems. Files are readable by everyone, directories are accessible by everyone, but only the owner can modify. 027 blocks others completely while allowing group read access. Good for files that should be shared with team members but not the whole system. 077 is the most restrictive - only the owner has any access. Good for sensitive files like private keys or personal data. 002 allows group members to write, making files group-collaborative by default. Useful in shared project directories. 007 combines group write access with blocking others completely. 000 applies no restrictions - everything is world-readable and writable. This is dangerous and almost never appropriate. The RHEL default is 022 for both regular users and root. Security-conscious organizations often set stricter defaults like 027 or 077, especially for system accounts.

Setting umask Temporarily

Use the umask command to change the value for your current shell session. The change lasts until you log out.

# Check current umask
[user@host ~]$ umask
0022

# Set more restrictive umask
[user@host ~]$ umask 077
[user@host ~]$ umask
0077

# Create a file with new umask
[user@host ~]$ touch private.txt
[user@host ~]$ ls -l private.txt
-rw-------. 1 user user 0 Jan 20 10:00 private.txt
# Only owner can read/write (600)

# Set using symbolic notation
[user@host ~]$ umask u=rwx,g=rx,o=
[user@host ~]$ umask
0027

Session only: This change is lost when you log out or open a new terminal. Use profile files for permanent changes.

Setting umask Permanently

Add the umask command to shell startup files to make it permanent. The location depends on whether you want it for one user or all users.

# For a single user: add to ~/.bashrc
[user@host ~]$ echo "umask 027" >> ~/.bashrc

# For a single user: or add to ~/.bash_profile
[user@host ~]$ echo "umask 027" >> ~/.bash_profile

# For all users: add to /etc/profile (requires root)
[root@host ~]# echo "umask 027" >> /etc/profile

# For all users: or create file in /etc/profile.d/
[root@host ~]# echo "umask 027" > /etc/profile.d/custom-umask.sh

# Apply changes to current session (or log out and in)
[user@host ~]$ source ~/.bashrc

File precedence: /etc/profile runs first (system-wide), then ~/.bash_profile or ~/.bashrc (user-specific). Later settings override earlier ones.

For permanent umask settings, add the umask command to shell startup files. For a single user, add it to ~/.bashrc or ~/.bash_profile. The difference is subtle: .bash_profile runs for login shells, .bashrc runs for interactive non-login shells. Adding to .bashrc usually covers most situations. For all users on the system, you need root access. Add to /etc/profile or create a file in /etc/profile.d/. The profile.d approach is cleaner because you do not modify the original profile file, making updates easier. Files in /etc/profile.d/ with .sh extension are sourced automatically. Startup files run in order: system-wide files first (/etc/profile, /etc/profile.d/*), then user files (~/.bash_profile, ~/.bashrc). Later settings override earlier ones, so user settings can override system defaults. After editing, source the file or log out and back in for changes to take effect.

umask in /etc/login.defs

/etc/login.defs sets default umask for new user accounts and is read by login processes.

# View current setting in login.defs
[root@host ~]# grep -i umask /etc/login.defs
UMASK           022

# To change system default, edit this file
[root@host ~]# vim /etc/login.defs
# Change: UMASK    027

# Also affects su - sessions
# This is the fallback if not set elsewhere

login.defs controls:

Default umask for logins
Password aging defaults
UID/GID ranges
Home directory creation

Override order:

/etc/login.defs (lowest)
/etc/profile and /etc/profile.d/
~/.bash_profile, ~/.bashrc (highest)

/etc/login.defs is another location that affects umask. This file configures login behavior system-wide, including the default umask for login sessions. The UMASK setting in login.defs is used when users log in, particularly for console logins and su - sessions. It provides a fallback value if nothing else sets umask. However, shell profile files typically run after login.defs is processed, so /etc/profile or user profile files can override this setting. login.defs also controls many other login-related settings: password aging policies, UID and GID ranges for new users, whether to create home directories, and more. When planning umask policy for a system, consider all these locations. The effective umask depends on which files set it and in what order they run. Typically, user files have the final say, then system profile files, with login.defs as the fallback.

Understanding the Math

Important: umask uses bitwise AND NOT, not simple subtraction. For typical values this looks like subtraction, but edge cases differ.

Actual operation: result = base AND (NOT umask)

Base (666)

110 110 110

NOT umask (NOT 022)

111 101 101

Result (AND)

110 100 100

= 644

Practical note: Simple subtraction works for most common values. The bit operation matters when umask has a bit set that the base does not have.

I want to clarify the actual mathematics behind umask. It is not simple subtraction - it is a bitwise operation. The result equals base AND (NOT umask). First, invert the umask bits. Then AND that with the base permissions. For umask 022 (binary 000 010 010), NOT gives 111 101 101. ANDing with 666 (binary 110 110 110) gives 110 100 100, which is 644. For typical values, this looks like subtraction and you can use that shortcut. But consider: what if umask is 033 and base is 666? Subtraction gives 633, but the bit operation gives 644. The umask cannot remove execute permission from files because files do not have it in the base. This is actually a feature. It means you cannot accidentally create executable files just by having a strange umask. The base permissions act as a ceiling - umask can only remove permissions that exist in the base, not add or change them unexpectedly.

Special Permission Bits

The leading digit in a 4-digit umask controls special permissions: setuid, setgid, and sticky bit.

Bit	Value	File Effect	Directory Effect
Setuid	4	Run as file owner	(no effect)
Setgid	2	Run as file group	New files inherit group
Sticky	1	(no effect)	Only owner can delete files

# 4-digit umask format: SUGO (Special, User, Group, Others)
[user@host ~]$ umask
0022     # Leading 0 = no special bits masked

# Special bits are rarely set via umask
# They're usually set explicitly with chmod when needed

# Example: setgid directory for group collaboration
[root@host ~]# chmod g+s /shared/project
[root@host ~]# ls -ld /shared/project
drwxrwsr-x. 2 root developers 6 Jan 20 10:00 /shared/project
#     ^ setgid bit (s instead of x)

When you see a 4-digit umask like 0022, the leading digit controls special permission bits. These are setuid (4), setgid (2), and sticky bit (1). Setuid on an executable makes it run with the file owner's privileges, not the user running it. Classic example is /usr/bin/passwd which runs as root to modify /etc/shadow. Setgid on an executable runs with the file group's privileges. On a directory, it causes new files to inherit the directory's group rather than the creator's primary group - very useful for shared project directories. Sticky bit on a directory means only the file owner (or root) can delete files, even if others have write permission. /tmp uses this. In practice, special bits are rarely controlled through umask. They are almost always set explicitly with chmod when needed. The leading zero in umask 0022 simply means "do not mask any special bits" - new files will not have setuid, setgid, or sticky by default, which is appropriate.

Practical Examples

# Scenario 1: Create private files
[user@host ~]$ umask 077
[user@host ~]$ touch secret.txt
[user@host ~]$ ls -l secret.txt
-rw-------. 1 user user 0 Jan 20 10:00 secret.txt

# Scenario 2: Create group-collaborative directory
[user@host ~]$ umask 002
[user@host ~]$ mkdir team-project
[user@host ~]$ ls -ld team-project
drwxrwxr-x. 2 user user 6 Jan 20 10:00 team-project
# Group members can add files

# Scenario 3: Process files with specific permissions
[user@host ~]$ (umask 077; touch temp-sensitive-data.txt)
[user@host ~]$ umask   # Still original value
0022
# Subshell umask didn't affect parent shell

# Scenario 4: Script that creates secure files
#!/bin/bash
umask 077
touch /var/log/myapp/secure.log
# Rest of script...

Let me show practical scenarios. For creating private files, set umask 077. Files are created with 600 permissions - only you can read or write them. Great for sensitive data. For group collaboration, umask 002 creates files with 664 and directories with 775. Group members get write access, enabling shared work. The subshell technique is powerful. Wrapping a command in parentheses runs it in a subshell. Setting umask there only affects that subshell. When it exits, you are back to your original umask. Perfect for one-off operations that need different permissions. Scripts that create sensitive files should set umask near the beginning. This ensures all files created by the script have appropriate permissions, regardless of the user's umask when they run the script. This is especially important for system scripts that run as root.

Checking Effective Permissions

# Always verify permissions after creating files
[user@host ~]$ touch testfile.txt
[user@host ~]$ ls -l testfile.txt
-rw-r--r--. 1 user user 0 Jan 20 10:00 testfile.txt

[user@host ~]$ mkdir testdir
[user@host ~]$ ls -ld testdir
drwxr-xr-x. 2 user user 6 Jan 20 10:00 testdir

# Check numeric permissions
[user@host ~]$ stat -c "%a %n" testfile.txt testdir
644 testfile.txt
755 testdir

# Detailed stat output
[user@host ~]$ stat testfile.txt
  File: testfile.txt
  Size: 0         	Blocks: 0          IO Block: 4096   regular empty file
Access: (0644/-rw-r--r--)  Uid: ( 1000/   user)   Gid: ( 1000/   user)
...

Best practice: After setting a new umask, create test files and directories to verify the permissions are what you expect.

Always verify permissions after creating files, especially when working with a new umask setting. ls -l shows permissions in symbolic form. This is quick and readable but requires mental translation to octal. For files, use ls -l. For directories, use ls -ld (the -d flag shows the directory itself, not its contents). stat provides more detailed information. The -c flag specifies format. %a gives octal permissions, %n gives the filename. This is useful in scripts or when you need the numeric value. Full stat output shows size, blocks, type, permissions in both octal and symbolic form, ownership, and timestamps. The Access line shows (0644/-rw-r--r--) - both representations together. Make it a habit to verify. Create a quick test file, check its permissions, then delete it. This confirms your umask is set correctly before creating important files.

Security Considerations

Too Permissive (umask 000)

Files: 666 (world writable!)
Dirs: 777 (world writable!)
Anyone can read/modify your files
Major security vulnerability
Never use in production

Too Restrictive (umask 077)

Files: 600 (owner only)
Dirs: 700 (owner only)
May break group collaboration
May prevent web servers from reading
Good for sensitive data

Balance needed: The right umask depends on the use case. System defaults (022) balance security and usability. Adjust based on actual needs.

# Service accounts often need stricter umask
# Example: database service creates files only it should access
# In service configuration or startup script:
umask 077

umask involves security trade-offs. Too permissive is dangerous. umask 000 creates world-writable files. Any user on the system can read, modify, or delete your files. This is almost never appropriate and represents a serious security vulnerability. Too restrictive can break functionality. umask 077 creates files only you can access. This might prevent legitimate access - group members cannot collaborate, web servers cannot read files you want to serve, backup systems might fail. The right choice depends on context. For regular user work, 022 is reasonable - files are readable but not world-writable. For sensitive data, 077 keeps it private. For shared projects, 002 or 007 enables collaboration. Service accounts often need strict umask. A database server should create files only it can read - using 077 prevents other users from accessing database files directly. Configure this in the service's startup configuration.

umask for Different Users

# System accounts (services) - often very restrictive
# Set in service unit files or startup scripts
[Service]
UMask=0077    # systemd unit file syntax

# Regular users - standard default
# /etc/profile or /etc/login.defs
UMASK 022

# Shared group users - allow group write
# ~/.bashrc for specific users
umask 002

# High-security users - private by default
# ~/.bashrc for security-sensitive accounts
umask 077

# PAM can also set umask based on user/group
# /etc/pam.d/login or /etc/security/limits.conf
[root@host ~]# grep pam_umask /etc/pam.d/login
session    optional     pam_umask.so umask=0027

Different users often need different umask values. Service accounts (like apache, mysql, postgres) typically need very restrictive umask. They create files that only the service should access. Set this in the systemd unit file with UMask=0077, or in the service's startup script. Regular users get the system default, typically 022. This provides reasonable security while allowing file sharing. Users in collaborative groups might need 002 to allow group writing by default. Set this in their individual ~/.bashrc files. High-security users (handling sensitive data, security team) might use 077 for private-by-default file creation. PAM can also set umask through pam_umask module. This allows policy-based umask assignment based on user, group, or other criteria. It is more complex but provides centralized control.

Troubleshooting

# Problem: Files created with wrong permissions
# Check current umask
[user@host ~]$ umask
0077    # Aha! That's why files are private

# Find where umask is being set
[user@host ~]$ grep -r "umask" ~/.bash* ~/.profile /etc/profile /etc/profile.d/ 2>/dev/null
/etc/profile.d/security.sh:umask 077

# Problem: Can't figure out why permissions are what they are
# Calculate expected vs actual
[user@host ~]$ umask
0022
# Expected file: 666 - 022 = 644
# Expected dir:  777 - 022 = 755

# Problem: Application creates files with unexpected permissions
# Some apps set their own umask internally
# Check app documentation or source code

# Problem: cron jobs create files with wrong permissions
# Set umask at the start of the cron script
#!/bin/bash
umask 022
# rest of script

When file permissions are not what you expect, troubleshoot systematically. First, check the current umask. It might be different from what you assumed. Use grep to find where umask is set. Check user profile files, system profile files, and /etc/profile.d/. Often an organization has added a custom umask script. If calculated permissions do not match actual permissions, consider that some applications set their own umask internally. Web servers, databases, and other services often have their own umask configuration independent of the user's shell umask. Cron jobs run with minimal environment and might not source your profile files. Always set umask explicitly at the beginning of cron scripts to ensure consistent permissions. Also remember that umask only affects newly created files. Existing files keep their current permissions. If old files have wrong permissions, use chmod to fix them.

Best Practices

Do

Understand your organization's policy
Use 022 for normal shared systems
Use 077 for sensitive data handling
Set umask in scripts that create files
Test umask changes before deploying
Verify permissions after file creation
Document non-standard umask settings
Configure services with appropriate umask

Do Not

Use 000 (no protection)
Assume all systems have same umask
Forget umask only affects new files
Rely on umask for security alone
Change system defaults without testing
Ignore umask in security audits
Forget services have separate umask
Set overly restrictive for collaboration

Remember: umask is just one part of file security. Combine with proper ownership, ACLs, SELinux, and principle of least privilege.

Let me summarize best practices for umask. Understand your organization's security policy - many have specific umask requirements. Use 022 for typical shared systems where files should be readable. Use 077 when handling sensitive data that should be private. Always set umask explicitly in scripts that create files. Do not rely on the environment having the right value. Test umask changes in a safe environment before deploying to production. An overly restrictive umask can break applications. Verify permissions after creating files, especially when using a new umask setting. Document any non-standard umask configurations so others understand why. Do not use 000 - there is almost no legitimate reason for world-writable files. Do not assume all systems have the same umask - verify. Remember umask only affects new files, not existing ones. Do not rely solely on umask for security - use proper ownership, ACLs when needed, and SELinux. umask is one layer in defense in depth.

Key Takeaways

umask: Removes permissions from defaults. Files start at 666, directories at 777. umask specifies what to subtract.

Calculate: File = 666 − umask, Directory = 777 − umask. Common: 022→644/755, 077→600/700.

Set: Temporary: umask 027. Permanent: add to ~/.bashrc or /etc/profile.d/.

Verify: Use ls -l or stat to confirm permissions. Test before production deployment.

LAB EXERCISES

Display current umask in octal and symbolic forms
Calculate expected permissions for umask 027
Create files with different umask values and verify
Set temporary umask and observe file creation
Configure permanent umask in ~/.bashrc
Use subshell technique for one-off permission changes

Next: Special Permissions (setuid, setgid, sticky bit)

Let me summarize the key points about umask. umask determines default permissions by removing permissions from base values. Files have a base of 666 (no execute), directories have 777 (with execute). The umask value specifies which permission bits to remove. For calculation, subtract umask from the base. With umask 022, files get 644 (readable by all, writable by owner) and directories get 755 (accessible by all, modifiable by owner only). With umask 077, both files and directories are accessible only by owner. To set umask temporarily, just run the umask command with the value. For permanent settings, add to shell profile files: ~/.bashrc for personal settings, /etc/profile.d/ for system-wide settings. Always verify permissions on created files using ls -l or stat. Do not assume - check. Test umask changes before deploying to production systems. Your lab exercises provide hands-on practice with displaying, calculating, setting, and verifying umask values.