The Permission Template
When you create a new file or directory, what permissions does it get? This is controlled by the umask (user mask), which acts as a subtractive filter applied at creation time.
How umask works:
The system starts with a maximum base permission:
- Files: 666 (rw-rw-rw-) — execute is never granted by default for files
- Directories: 777 (rwxrwxrwx)
The umask value specifies which permission bits to remove from this base. The result is the permission for newly created files and directories.
Final permission = Base permission AND NOT(umask)
In practice, for simple cases, you can think of it as subtraction:
File: 666 - 022 = 644
Directory: 777 - 022 = 755
Common umask values:
| Umask | Files (666 -) |
Directories (777 -) |
Effect |
|---|---|---|---|
022 (most common default) |
644 (rw-r--r--) |
755 (rwxr-xr-x) |
Owner has full read-write access; everyone else can read |
002 (shared dev environments) |
664 (rw-rw-r--) |
775 (rwxrwxr-x) |
Group members can write to new files by default |
077 (maximum privacy) |
600 (rw-------) |
700 (rwx------) |
Only the owner can access anything |
The umask command itself both reports and sets the value for the current shell session; making it permanent means placing that setting in a shell startup file (~/.bashrc, ~/.profile) for a single user, or in /etc/profile / /etc/login.defs system-wide.
Why umask matters in production:
In multi-user systems or when running services, the umask determines whether newly created files are readable by other users or services. A web application creating upload files with a 022 umask makes them world-readable — if those uploads contain sensitive data, that's a security vulnerability that's easy to miss. Setting a restrictive umask (e.g., 077) before a process starts means every file it creates comes out owner-only from the moment it's written, without a single chmod call ever being needed.
A common interview question: "A service is creating log files that are world-readable, but you need them to be group-readable only. How do you fix this without modifying the application code?" Answer: Set the appropriate umask in the service's startup script or systemd unit file (e.g., UMask=0027 in the [Service] section of the unit file). This is better than a cron job running chmod because it's preventative rather than reactive—the files are created with the right permissions from the start.
Key Point: In production environments, especially for service accounts (e.g.,
www-data,postgres), always verify the umask setting. Many security vulnerabilities arise from services creating files with overly permissive defaults. Check the service's systemd unit file for aUMask=directive. For example, a database service should typically haveUMask=0077to ensure data files are not readable by other users on the system.