Users, groups & permissions · Prasanta Kumar Behera

Understand who owns every file and who may read, write or run it. Users and groups, the rwx permission model in letters and numbers, chmod and chown, sudo, and the special cases that trip people up.

Reading a permission string: owner, group, others.

Every file has an owner, a group, and three sets of rights

$ ls -l deploy.sh
-rwxr-x--- 1 asha devops 1204 Sep 27 09:30 deploy.sh
│└┬┘└┬┘└┬┘   └┬─┘ └──┬─┘
│ │  │  │     │      └─ group: devops
│ │  │  │     └─ owner: asha
│ │  │  └─ others: --- (nothing)
│ │  └─ group: r-x (read, execute)
│ └─ owner: rwx (read, write, execute)
└─ type: - file, d directory, l symlink

Every file is like a diary with three lists on its cover: what the owner may do, what the owner's club (group) may do, and what everyone else may do. Each list has three boxes: read it, write in it, and for programs, run it. chmod ticks and unticks the boxes; chown changes whose diary it is.

What r, w, x mean

	On a file	On a directory
r (read)	Read the contents	List the names inside
w (write)	Change the contents	Create, rename, delete files inside
x (execute)	Run it as a program	Enter it (`cd`) and reach files inside

Note the directory rule: deleting a file needs w on the directory, not on the file.

Numbers (octal) and letters

Each set is a sum: r = 4, w = 2, x = 1.

Number	Letters	Typical use
7	rwx	Owner of scripts and directories
6	rw-	Owner of normal files
5	r-x	Others entering directories or running programs
4	r--	Read-only
0	---	No access

$ chmod 640 app.env        # owner rw, group r, others nothing: good for config with secrets
$ chmod 755 deploy.sh      # owner rwx, everyone else r-x
$ chmod u+x,g-w file       # letters: add x for user, remove w for group
$ sudo chown app:app /srv/app -R

Users, groups and root

Users are listed in /etc/passwd; groups in /etc/group; password hashes in /etc/shadow (root-only).
root (user ID 0) bypasses normal permission checks. Treat a root shell with great care.
Service accounts such as www-data, postgres and nobody let each service run with only its own files. If it's compromised, the damage is limited.

$ id
uid=1000(asha) gid=1000(asha) groups=1000(asha),27(sudo),1001(devops)
$ sudo adduser deploy
$ sudo usermod -aG devops deploy     # -a append, -G supplementary group

Group changes apply at the next login (or run newgrp devops).

sudo: borrowing root, carefully

sudo runs one command as root (or another user), is logged, and is controlled by /etc/sudoers. Always edit that with visudo, which checks your syntax so you can't lock yourself out.

$ sudo -l                    # what may I run?
$ sudo systemctl restart nginx
$ sudo -u postgres psql      # run as a different user

umask: default permissions

New files start from 666 and directories from 777, minus the umask. With the common umask 022, new files are 644 and new directories 755. A umask of 027 (files 640, directories 750) is a common hardening choice for servers.

$ umask
0022

Try it: a shared team folder

Create a group devops and two users alice and bob; add both to devops.
Create /srv/shared, owned by root:devops, mode 2770. The leading 2 is setgid: new files inherit the directory's group.
As alice (sudo -u alice touch /srv/shared/plan.txt), create a file; check its group with ls -l.
As bob, append to it. Did it work? If not, which permission is missing, and on what?
Confirm a user outside devops can't even list the directory.

Going deeper: special bits and ACLs

setuid (4xxx) runs a program as its owner (passwd uses it to edit /etc/shadow); setgid on directories keeps group ownership; the sticky bit (1xxx, as on /tmp) lets users delete only their own files. Audit setuid files: find / -perm -4000 -type f 2>/dev/null.
ACLs (setfacl, getfacl) grant extra users or groups access beyond owner/group/other. A + at the end of the ls -l permissions means an ACL is present.
Containers inherit these rules: files in images and volumes have numeric owners (UIDs). "Permission denied" in a pod is often a UID mismatch, fixed with securityContext.runAsUser/fsGroup rather than chmod 777.

Recap

Every file: owner, group, others, each with r, w, x. On directories, x = enter, w = create and delete inside.
Octal: r=4, w=2, x=1. Common modes: 644, 640, 755, 750, 600.
chmod changes rights, chown changes ownership, usermod -aG adds groups (-a!).
Use sudo for single commands, visudo for its config, and never "fix" things with 777.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.