Linux users, groups and permissions

01Users, groups and root

A user is an identity with a numeric ID (UID). Humans are users, but so are services: nginx usually runs as www-data on Ubuntu (nginx on RHEL), PostgreSQL as postgres. A group is a named set of users, which lets you give several users the same access. root (UID 0) can do anything and bypasses normal permission checks, which is why you should not work as root day to day. User accounts are listed in /etc/passwd, password hashes in /etc/shadow (readable only by root), and groups in /etc/group. The id command shows who you are and which groups you belong to.

1whoami                       # current user
2id                           # uid, gid and all groups
3id www-data                  # who is the web server user?
4getent passwd your_user      # account details
5groups your_user             # group membership
6sudo adduser your_user       # create a user (Debian/Ubuntu, interactive)
7sudo useradd -m -s /bin/bash your_user   # portable, non-interactive
8sudo usermod -aG www-data your_user      # ADD to a group (-a matters!)

02Reading rwx and octal permissions

Run ls -l and you will see something like -rw-r--r-- 1 deploy www-data. The first character is the type (- file, d directory, l link). Then come three triplets: the owner's rights, the group's rights and everyone else's. r is read, w is write, x is execute. On a directory the meaning shifts: r lets you list names, w lets you create and delete files inside, and x lets you enter it and reach files by path. Each triplet is also a number: r = 4, w = 2, x = 1, added together. So 644 is rw-r--r-- (owner writes, others read), 755 is rwxr-xr-x, 600 is private to the owner and 640 lets the group read.

• 644: normal files. 755: directories and scripts. 600: secrets like SSH keys and .env files.
• 640 / 750: owner full, group read-only, others nothing; good for app config shared with the web server group.
• 777 means anyone on the system can write. It hides the real problem and opens a security hole.
• Special bits: setgid on a directory (2775) makes new files inherit the directory's group; sticky bit (1777, as on /tmp) stops users deleting others' files.

03chmod, chown and fixing ownership

chmod changes permissions, chown changes owner and group. Both accept -R for recursive changes, which is powerful and dangerous: a careless chmod -R on the wrong directory can break SSH or a whole system. Use symbolic modes for small, precise changes (u+x adds execute for the owner, g-w removes write from the group) and octal modes when you want an exact result. A common pattern is to give files and directories different modes using find, because directories need x and normal files usually should not have it.

1chmod 600 ~/.ssh/id_ed25519          # private key: owner only
2chmod u+x deploy.sh                   # make a script executable
3chmod g-w config.php                  # remove group write
4sudo chown deploy:www-data -R /var/www/app
5# Directories 755, files 644, in one tree
6find /var/www/app -type d -exec chmod 755 {} +
7find /var/www/app -type f -exec chmod 644 {} +
8# Inspect a path permission by permission
9namei -l /var/www/app/storage/logs/app.log

04sudo and /etc/sudoers

sudo runs a single command as root (or another user) after checking that you are allowed to. Every use is logged, which is much better for accountability than sharing a root password. On Ubuntu, members of the sudo group get full sudo rights; on RHEL the group is wheel. Rules live in /etc/sudoers and in files under /etc/sudoers.d. Never edit them with a normal editor: use visudo, which checks the syntax before saving. A broken sudoers file can lock everyone out of sudo. You can also grant narrow rights, for example letting a deploy user restart one service without a password and nothing else. Recent Ubuntu releases ship sudo-rs, a memory-safe rewrite with the same commands and config.

1sudo usermod -aG sudo your_user     # full sudo (wheel on RHEL)
2sudo -l                             # what am I allowed to run?
3sudo -u postgres psql               # run as another user
4sudo visudo -f /etc/sudoers.d/deploy
5# Content of /etc/sudoers.d/deploy:
6deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp.service

05umask, service users and ACLs

umask decides the default permissions of new files by removing bits. The common default 022 gives new files 644 and new directories 755; a umask of 002 gives 664 and 775, which suits teams sharing a group. For apps, create a dedicated system user with no login shell, and make it the owner of only what the app must write. ACLs (access control lists) add extra rules on top of the owner/group/other model, for example giving one more user write access to a single directory. They are handy, but hidden from a quick ls -l (look for a + at the end of the mode), so use them sparingly and document them.

1umask                                   # show current mask, e.g. 0022
2sudo useradd --system --no-create-home --shell /usr/sbin/nologin myapp
3sudo chown -R myapp:myapp /var/lib/myapp
4# ACL: let www-data write to one directory, now and for new files
5sudo setfacl -R -m u:www-data:rwX /var/www/app/storage
6sudo setfacl -R -d -m u:www-data:rwX /var/www/app/storage
7getfacl /var/www/app/storage

06The classic bug: the web server cannot write

A typical case: a PHP or Node app works locally but in production logs 'Permission denied' when it writes cache, logs or uploads. The cause is almost always that the code was deployed by one user (deploy or root) while the app runs as another (www-data or a PHP-FPM pool user). The fix is not 777. Instead, find out which user the process runs as, keep the code owned by the deploy user and read-only for the app, and give the app write access only to the directories that really need it, such as storage and bootstrap/cache in Laravel. Using the setgid bit keeps new files in the right group. Also remember that deploying or running artisan commands as root can create root-owned cache files the app then cannot overwrite.

1ps -o user,pid,cmd -C php-fpm8.3     # which user runs PHP? (adjust version)
2ps -o user,pid,cmd -C node
3cd /var/www/app
4sudo chown -R deploy:www-data .
5sudo chmod -R 750 .
6sudo chmod -R 2775 storage bootstrap/cache     # group write + setgid
7sudo find storage bootstrap/cache -type f -exec chmod 664 {} +
8sudo -u www-data php artisan cache:clear       # run as the app user, not root

07How the kernel actually checks access

On every open, the kernel compares the process's effective UID and its groups (primary plus supplementary) with the file's owner and group. The check picks exactly one class, in order: if you are the owner, only the owner bits count; otherwise if one of your groups matches, only the group bits count; otherwise the other bits. Classes do not add up, so a file with mode 0077 denies its own owner even though everyone else can read it. Reaching a file also needs x (search) permission on every directory along the path, which namei -l shows at a glance. Deleting or renaming a file depends on write permission on the directory, not the file. Root skips most of these checks not by magic but through capabilities such as CAP_DAC_OVERRIDE, and a running process keeps the group list it had at login, which is why new group membership needs a new session.

1cat /proc/self/status | grep -E '^(Uid|Gid|Groups)'   # real/effective IDs
2chmod 077 test.txt && cat test.txt      # owner denied: only owner bits apply
3namei -l /srv/app/shared/.env           # x needed on every directory
4sudo -u www-data test -r /srv/app/shared/.env && echo readable
5newgrp www-data                          # pick up a new group without relogin

08setuid, setgid and capabilities

A setuid program runs with the privileges of its owner rather than the caller; passwd and sudo are setuid root so ordinary users can change protected files in controlled ways. Every setuid-root binary is attack surface, so audit them and never set the bit on scripts or your own tools. Linux capabilities split root's power into about forty pieces, so a program can receive just one: cap_net_bind_service lets a non-root process bind ports below 1024, cap_net_raw lets ping send raw packets. File capabilities are set with setcap, and systemd can grant them to a service with AmbientCapabilities while dropping everything else with CapabilityBoundingSet. Filesystems can also be mounted with nosuid, nodev and noexec, which is a cheap hardening step for upload and temporary directories that should never contain runnable programs.

1find / -xdev -perm -4000 -type f 2>/dev/null   # setuid binaries
2getcap -r /usr/bin 2>/dev/null                 # files with capabilities
3sudo setcap 'cap_net_bind_service=+ep' /usr/local/bin/myserver
4# In a systemd unit, instead of setcap:
5#   AmbientCapabilities=CAP_NET_BIND_SERVICE
6#   CapabilityBoundingSet=CAP_NET_BIND_SERVICE
7findmnt -o TARGET,OPTIONS /tmp                  # check nosuid,noexec

09When the modes are right but access is still denied

If ls -l looks perfect and the app still gets EACCES, something above the classic model is saying no. Mandatory access control is the usual suspect: AppArmor on Ubuntu restricts confined programs to the paths in their profile, and SELinux on RHEL labels every file and process and denies anything the policy does not allow, regardless of owner and mode. On SELinux a file moved (rather than copied) into a web root keeps its old label, a classic cause of 403 errors; restorecon fixes it. Other hidden layers: the immutable attribute set with chattr +i, which blocks even root until removed; read-only or noexec mounts; ACL masks that cap group entries; and, in containers, user namespaces that map container root to an unprivileged host UID. Check these before you touch modes.

1sudo aa-status                        # AppArmor profiles in enforce mode
2sudo journalctl -k | grep -i apparmor  # AppArmor denials
3ls -Z /var/www/html                    # SELinux labels (RHEL family)
4sudo ausearch -m avc -ts recent        # SELinux denials
5sudo restorecon -Rv /var/www/html      # reset labels to policy defaults
6lsattr /etc/resolv.conf                # 'i' = immutable
7getfacl /srv/app/storage | grep mask   # ACL mask limiting entries

10UIDs across containers and volumes

The kernel stores numbers, not names. A file owned by UID 1000 belongs to whoever has UID 1000 in the current user database, which differs between your host and a container image. That is why bind-mounted directories often show strange owners or become unwritable: the container process runs as UID 33 (www-data in Debian images) or 1000 (node in the official Node images), while the host files belong to your deploy user. Solutions, from simplest: run the container with the host's UID and GID (user: "1000:1000" in Compose), chown the volume to the container's UID, or use named volumes that Docker initializes. Rootless Docker and Podman add user namespaces, so container root maps to a high unprivileged UID on the host, which improves security but shifts the numbers you see on disk. systemd's DynamicUser allocates a transient UID per service in the same spirit.

1docker compose exec app id                  # UID inside the container
2stat -c '%u:%g %n' ./storage                # numeric owner on the host
3# docker-compose.yml
4#   services:
5#     app:
6#       user: "1000:1000"                   # match the host deploy user
7cat /etc/subuid                             # ranges for rootless containers