20 minusersgroupspermissionssecurity

Users, Groups & Permissions

Learn users, groups & permissions concepts for DevOps interviews

02 — Users, Groups & Permissions

Most “it works on my machine / permission denied / the service can’t write” incidents are permission problems. This file makes you fluent in rwx, ownership, the special bits (setuid/setgid/sticky), umask, sudo, and ACLs — and the exact way the kernel decides access.

1. Identity: users and groups

Every user has a UID; every group a GID. The kernel checks numbers, not names.
UID 0 = root (the superuser, bypasses permission checks).
A user has one primary group and any number of supplementary groups.

id                       # your uid, gid, groups
id nginx                 # another user's ids
whoami
getent passwd arpit      # user record (from /etc/passwd or LDAP etc.)
groups arpit             # groups a user belongs to

Key files:

File	Holds
`/etc/passwd`	user accounts: `name:x:uid:gid:comment:home:shell` (`x` = password is in shadow)
`/etc/shadow`	hashed passwords + aging (root-only)
`/etc/group`	groups and their members
`/etc/sudoers`	who can `sudo` (edit with `visudo`)

⚠️ A system/service user typically has a non-login shell (/usr/sbin/nologin) and no password — it exists to own files and run a daemon, not to log in. Interviewers ask “why does nginx have a user?” → least privilege: the daemon runs as an unprivileged account so a compromise is contained.

2. Reading `ls -l` permissions

-rwxr-xr--  1 arpit devs 4096 Sep 27 10:00 deploy.sh
│└┬┘└┬┘└┬┘    │     │
│ │  │  └ other:  r--  (read)
│ │  └─── group:  r-x  (read, execute)
│ └────── user :  rwx  (read, write, execute)
└──────── type :  -    (regular file)
             owner=arpit  group=devs

Three classes — user (owner), group, other — each with r (4), w (2), x (1).

On a file	On a directory
`r` = read contents	`r` = list names in it
`w` = modify contents	`w` = create/delete/rename entries in it
`x` = execute it	`x` = enter/traverse it (`cd`), access items by name

⚠️ Two classic traps:

Deleting a file needs w+x on the directory, not on the file. You can delete a file you can’t even read if you own the directory.
x without r on a directory lets you access a known path inside but not list it.

chmod 750 deploy.sh        # rwx r-x --- (numeric/octal)
chmod u+x,g-w deploy.sh    # symbolic
chown arpit:devs file      # change owner and group
chgrp devs file            # change group only
chmod -R o-rwx /secret     # recursive

🎯 Interview signal: fluently converting 750 ⇄ rwxr-x--- and explaining directory x as “traverse” vs r as “list” separates confident candidates from memorizers.

3. The special bits: setuid, setgid, sticky

Beyond rwx there are three special bits (a 4th leading octal digit):

Bit	Octal	On a file	On a directory
setuid	4000	Run the file as its owner (e.g., `passwd` runs as root)	(no effect)
setgid	2000	Run as its group	New files inherit the directory’s group
sticky	1000	(no effect)	Only the file owner can delete their files (e.g., `/tmp`)

ls -l /usr/bin/passwd     # -rwsr-xr-x  → the 's' is setuid root
chmod 4755 mybin          # set setuid
ls -ld /tmp               # drwxrwxrwt → the 't' is the sticky bit
chmod 2775 /shared        # setgid dir: files created inside get group = dir's group

setuid on passwd is why a normal user can update /etc/shadow (which is root-only): the binary runs with the owner’s (root’s) privileges temporarily.
setgid on a directory is the standard trick for shared team folders — every file created inside inherits the group, so the whole team can collaborate.
sticky on /tmp stops users from deleting each other’s files in a world-writable dir.

⚠️ setuid root binaries are a security risk — a bug in one becomes a privilege-escalation path. Auditing them (find / -perm -4000 -type f) is a hardening step (file 12).

🎯 Interview signal: uppercase S/T in ls -l means the special bit is set but the underlying x is not — a subtle detail that impresses.

4. `umask` — default permissions

New files don’t get 777/666 — the umask subtracts permissions.

Base: files start from 666, directories from 777.
Result = base minus umask.

umask            # e.g., 022
# file:  666 - 022 = 644  (rw-r--r--)
# dir :  777 - 022 = 755  (rwxr-xr-x)
umask 077        # stricter: new files 600, dirs 700 (owner-only) — good for sensitive svc users

⚠️ Interviewers ask “why did my new file come out 644 when I didn’t set that?” → the umask. A service creating world-readable files may need a tighter umask (e.g., 027).

5. `sudo` — controlled privilege escalation

sudo runs a command as another user (default root), governed by /etc/sudoers.

sudo systemctl restart nginx      # run one command as root
sudo -u postgres psql             # run as a specific user
sudo -l                           # what am I allowed to run?
visudo                            # SAFELY edit sudoers (validates syntax)

/etc/sudoers snippets:

# user  host = (runas) commands
arpit   ALL=(ALL:ALL) ALL                 # full sudo
%devs   ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx   # group, no password, one command

🎯 Interview signal: prefer sudo with least privilege (specific commands per group) over sharing the root password or su -. sudo gives per-command control and an audit trail (who ran what, in the logs). ⚠️ Always use visudo — a syntax error in sudoers edited by hand can lock everyone out of sudo.

6. ACLs — beyond user/group/other

Standard permissions only express one owner and one group. POSIX ACLs grant extra users/groups specific rights.

getfacl file                        # view ACLs
setfacl -m u:deploy:rx script.sh    # give user 'deploy' read+execute
setfacl -m g:audit:r  logfile       # give group 'audit' read
setfacl -x u:deploy   script.sh     # remove that ACL entry

⚠️ A + at the end of ls -l perms (-rw-r--r--+) means ACLs are present — don’t forget to getfacl when perms “look right” but access still fails.

7. How the kernel decides access (the algorithm)

For a given process accessing a file:

root (UID 0) → allowed (with minor exceptions like x needing at least one x bit).
If the process UID == file owner → use the user bits (only).
Else if the process is in the file’s group (or an ACL matches) → use group/ACL bits.
Else → use other bits.

⚠️ The classes are checked in order and exclusively — if you’re the owner, the group/other bits don’t add permissions. So ----rwxrwx means the owner has no access even though group/other do. This “owner is most specific, not most powerful” point is a favorite trick question.

Interview Questions

Q1. Explain rwx for files vs directories.

On a file: read = view contents, write = modify contents, execute = run it. On a directory: read = list the names inside, write = create/delete/rename entries in it, execute = traverse/enter it and access items by name. The key subtlety is that deleting a file depends on write+execute on the containing directory, not on the file’s own permissions.

Q2. Convert 750 to symbolic and say what it means.

rwxr-x---: owner has read/write/execute, group has read/execute, other has nothing. Common for a script only the owner should edit but the team can run.

Q3. What are setuid, setgid, and the sticky bit?

setuid on an executable makes it run as the file’s owner (e.g., passwd runs as root so a user can change their password in root-owned /etc/shadow). setgid on an executable runs as the file’s group; on a directory it makes new files inherit the directory’s group — used for shared team folders. The sticky bit on a directory (like /tmp) restricts deletion so only a file’s owner can remove it, even though the directory is world-writable.

Q4. Why does passwd work for a normal user when /etc/shadow is root-only?

passwd is a setuid-root binary. When a normal user runs it, it executes with the owner’s (root’s) effective privileges just for that program, so it can update the root-owned shadow file in a controlled way. That’s exactly why setuid-root binaries must be trusted and audited.

Q5. What is umask and how does it affect new files?

umask is the set of permission bits removed from the defaults when files/dirs are created. Files start from 666 and directories from 777, then the umask is subtracted. With umask 022 a new file is 644 and a new directory 755. A service handling sensitive data might use 077 so new files are owner-only.

Q6. How do you delete a file you don’t own and can’t read?

If you have write+execute on the containing directory, you can delete it — deletion is a directory operation, not a file operation. Ownership/permissions of the file itself don’t matter (unless the sticky bit is set on the directory, which restricts deletion to the file’s owner).

Q7. When do you use ACLs instead of standard permissions?

When you need to grant specific rights to more than one user or group beyond the single owner/group/other model — e.g., give the deploy user read/execute and the audit group read on the same file without changing ownership. setfacl/getfacl manage them, and a + in ls -l shows ACLs are present.

Q8. How should you grant admin rights to a team — root password, su, or sudo?

sudo with least privilege. Put admins in a group and grant that group only the specific commands they need in /etc/sudoers (edited with visudo). It avoids sharing root’s password, scopes what each person can do, and produces an audit trail of who ran what.

Q9. (Senior) A file shows ----rwxrwx and the owner can’t read it but others can. Explain.

Permission classes are evaluated most-specific-first and exclusively. Since the accessing user is the owner, only the owner (user) bits apply — and they’re ---, so access is denied. The group/other bits never get considered for the owner. Being the owner makes you the most specific class, not the most privileged one.

Next: 03 — Processes & Signals — how programs actually run and how you control them.