Stackvora.tech

Linux Permissions Deep Dive: chmod, chown, umask and ACLs

Managing file and directory permissions is fundamental to Linux system security and operational integrity. Incorrectly configured permissions can expose…

Managing file and directory permissions is fundamental to Linux system security and operational integrity. Incorrectly configured permissions can expose sensitive data, disrupt services, or prevent legitimate users from accessing necessary resources. This article provides an in-depth exploration of standard Unix permissions, special permission bits, the role of umask, and advanced Access Control Lists (ACLs).

Understanding these mechanisms is crucial for system administrators, developers, and anyone responsible for securing data on Linux environments, ensuring robust control over who can read, write, or execute specific files and directories.

Standard Unix Permissions: Owners, Groups, and Others

Linux permissions are organized into three primary categories: owner, group, and others. For each category, three basic permissions apply: read (r), write (w), and execute (x).

  • Owner: The user account that owns the file or directory.
  • Group: A specific group of users. All members of this group inherit the defined permissions.
  • Others: All other users on the system not explicitly covered by the owner or group permissions.

Permissions are often represented numerically (octal) or symbolically.

Octal Permission Representation (Cheat Sheet)

  • r (read) = 4
  • w (write) = 2
  • x (execute) = 1
  • No permission = 0

To calculate the octal value for a permission set, sum the values for read, write, and execute for each category. For example:

  • 755:
    • Owner: rwx (4+2+1 = 7)
    • Group: r-x (4+0+1 = 5)
    • Others: r-x (4+0+1 = 5)

    This is typical for executables or directories, allowing the owner full control and others to read/execute.

  • 644:
    • Owner: rw- (4+2+0 = 6)
    • Group: r-- (4+0+0 = 4)
    • Others: r-- (4+0+0 = 4)

    This is typical for regular files, allowing the owner to read/write and others to only read.

  • 700:
    • Owner: rwx (7)
    • Group: --- (0)
    • Others: --- (0)

    Grants exclusive access to the owner.

chmod: Changing File Permissions

The chmod command modifies file and directory permissions. It accepts both octal and symbolic modes.

Octal Mode Example:

# Set permissions to rwxr-xr-x for /opt/myapp/script.sh
chmod 755 /opt/myapp/script.sh

# Set permissions to rw-r--r-- for /var/www/html/index.php
chmod 644 /var/www/html/index.php

# Recursively change permissions for all files and directories under /srv/data
# Note: For directories, 'x' is often needed to traverse.
# It's usually better to handle files and directories separately with find.
chmod -R 755 /srv/data

Symbolic Mode Example:

Symbolic mode uses characters to represent user (u), group (g), others (o), and all (a), combined with operators (+ for add, - for remove, = for set exactly) and permission letters (r, w, x).

# Grant execute permission to group and others
chmod go+x /home/user/myscript.sh

# Remove write permission from others
chmod o-w /etc/myconfig.conf

# Set owner to rwx, group to r-x, and others to r-x
chmod u=rwx,g=rx,o=rx /srv/web/app/

chown and chgrp: Changing Ownership

The chown command changes the owner and/or group of a file or directory. The chgrp command changes only the group. Only root or the current owner (for group change) can typically use these commands.

# Change owner to 'john' for /home/john/document.txt
chown john /home/john/document.txt

# Change group to 'devs' for /opt/project/
chown :devs /opt/project/

# Change owner to 'admin' and group to 'ops' for /var/log/app.log
chown admin:ops /var/log/app.log

# Recursively change owner and group for /var/www/html/
chown -R www-data:www-data /var/www/html/

# Example using chgrp (less common as chown can do both)
chgrp engineers /srv/code/

Special Permission Bits

Beyond the standard rwx permissions, three special permission bits offer enhanced control:

  • setuid (4): When set on an executable file, the program runs with the permissions of the file's owner, not the user executing it. A common example is /usr/bin/passwd, which needs root privileges to write to /etc/shadow. This is denoted by an s in the owner's execute field (e.g., -rwsr-xr-x).
  • setgid (2):
    • On an executable file: Similar to setuid, but the program runs with the permissions of the file's group. Denoted by an s in the group's execute field (e.g., -rwxr-sr-x).
    • On a directory: New files and subdirectories created within this directory will inherit the directory's group ownership, rather than the primary group of the user creating them. This is extremely useful for shared project directories. Denoted by an s in the group's execute field (e.g., drwxr-sr-x).
  • sticky bit (1): When set on a directory, it restricts file deletion. Only the owner of a file (or the directory owner or root) can delete or rename files within that directory, even if they have write permission to the directory itself. The most common example is /tmp. Denoted by a t in the others' execute field (e.g., drwxrwxrwt).

Setting Special Permissions with chmod

Special bits are set by preceding the octal mode with an additional digit:

# Set setuid bit on an executable script
chmod 4755 /usr/local/bin/myscript

# Set setgid bit on a shared project directory
chmod 2770 /srv/projects/team_alpha

# Set sticky bit on a directory
chmod 1777 /var/shared_uploads

If the execute bit for the relevant category (owner for setuid, group for setgid, others for sticky) is not set, the special bit appears as a capital letter (e.g., S or T), indicating it's set but ineffective in some contexts, or implying a missing execute permission where it would usually be.

umask: Default File Creation Permissions

The umask command controls the default permissions assigned to newly created files and directories. It represents a bitmask of permissions that are removed from the default maximum permissions.

  • Default max for files: 666 (rw-rw-rw-) - execute bit is never set by default for new files.
  • Default max for directories: 777 (rwxrwxrwx)

The umask value is subtracted from these maximums. Common umask values:

  • 0022 (often shown as 022):
    • For files: 666 - 022 = 644 (rw-r--r--)
    • For directories: 777 - 022 = 755 (rwxr-xr-x)

    This is a common default for many systems, allowing the owner full access and others read-only access.

  • 0002 (often shown as 002):
    • For files: 666 - 002 = 664 (rw-rw-r--)
    • For directories: 777 - 002 = 775 (rwxrwxr-x)

    This is typical in environments where users share a primary group, allowing group members to write to new files.

To view your current umask:

$ umask
0022

To set a umask (usually in ~/.bashrc, /etc/profile, or /etc/login.defs):

# Set umask to 002 (group write allowed)
umask 002

POSIX Access Control Lists (ACLs)

Standard Unix permissions are limited to one owner, one group, and "others." POSIX ACLs extend this model, allowing granular permissions to be defined for arbitrary users and groups beyond the owner/group. This is particularly useful in complex multi-user environments.

ACLs are not enabled by default on all filesystems. Filesystem support (e.g., ext3, ext4, XFS) is required, and often mounted with the acl option in /etc/fstab. For instance:

UUID=a1b2c3d4-e5f6-7890-1234-567890abcdef /srv/data ext4 defaults,acl 0 2

getfacl: Viewing ACLs

The getfacl command displays ACLs for files and directories.

$ getfacl /srv/data/project_files/
# file: /srv/data/project_files/
# owner: project_admin
# group: developers
user::rwx
group::r-x
other::r-x

When an ACL is set, an additional "mask" entry appears, indicating the maximum effective permissions for users and groups defined in the ACL. The ls -l output for a file with an ACL will show a + after the permission string (e.g., -rwxr-xr-x+).

setfacl: Setting ACLs

The setfacl command modifies ACLs.

  • -m: Modify ACL entries.
  • -x: Remove ACL entries.
  • -b: Remove all extended ACL entries.
  • -R: Recursive.
  • -d: Set default ACLs for directories (inherited by new files/directories).

Examples:

# Grant user 'alice' read, write, and execute permissions to a directory
setfacl -m u:alice:rwx /srv/data/project_files/

# Grant group 'analysts' read-only access to a specific file
setfacl -m g:analysts:r-- /srv/data/reports/q4_2023.pdf

# Remove 'bob's specific permissions
setfacl -x u:bob /srv/data/project_files/

# Set a default ACL for a directory: new files/dirs will grant 'bob' read/write
setfacl -m d:u:bob:rw- /srv/data/shared_workspace/

# Apply default ACL recursively
setfacl -R -m d:u:bob:rw- /srv/data/shared_workspace/

# The mask entry is automatically calculated. To set it manually:
setfacl -m m:rwx /srv/data/project_files/

Note: When extended ACLs are in use, the "group" permissions shown by ls -l for files with ACLs actually reflect the effective permissions dictated by the "mask" entry, not necessarily the actual permissions for the primary group.

Common Pitfalls and Troubleshooting

  • Confusing Octal Values: A common mistake is using 777 for files (granting execute) when 666 or 644 is usually intended.
  • chmod -R on Mixed Content: Applying chmod -R 777 /path will set execute bit for all files, which is rarely desired and can be a security risk. Use find to differentiate: 
    find /path -type f -exec chmod 644 {} +
find /path -type d -exec chmod 755 {} +
  • Missing Execute Bit on Directories: If a directory lacks the execute (x) bit for a user/group, they cannot cd into it or access its contents, even if they have read (r) permission. For directories, r means listing contents, x means entering/traversing, and w means creating/deleting.
  • umask and Scripts: Shell scripts (e.g., in /etc/profile.d/) or system services might set their own umask, overriding user defaults.
  • ACLs and Mask Interaction: Always check getfacl output. The effective permissions for any named user or named group ACL entry, and for the base group entry, are the logical AND of their permissions with the mask entry. If the mask is too restrictive, it can inadvertently limit legitimate access. If you set a default ACL on a directory, files created within it will inherit those defaults, but may still be subject to the user's current umask.
  • Filesystem ACL Support: If setfacl returns errors like "Operation not supported," verify your filesystem is mounted with the acl option.

Back to the knowledge base · Ask the AI assistant