Users, permissions, and processes / Stage 4 of 13 · step 6 of 7

The team's shared directory

~25 min

Not running Starting usually ~20 s

Situation

The devs team, alice and bob, works in the /srv/team directory:

/srv/team/docs holds documents the team edits together;
/srv/team/reports holds reports: everyone drops their own there.

This week's complaints. bob: "I can't append to alice's plan.md: Permission denied. And I can't create my own document in docs." alice: "My report disappeared from reports: bob deleted it while sorting his own. And nobody but me can edit my new documents."

You don't need alice's or bob's passwords: sudo -u runs commands on their behalf, and sudo -iu runs them the way their login does.

Task

New files by alice and bob in /srv/team/docs get the devs group.
bob can append to a new document that alice creates after logging in.
bob can append to /srv/team/docs/plan.md, and alice stays the file's owner.
bob cannot delete or rename alice's report in /srv/team/reports.
alice and bob can put their own reports into /srv/team/reports, and new reports get the devs group.
Others outside devs get no write access: not to docs or reports, not to plan.md, and not to alice's new files.

The machine has no internet access; everything you need is already installed.

Lab goals

0 of 6

New files by alice and bob in /srv/team/docs get the devs group — not checked yet
bob can append to a new document alice created after logging in — not checked yet
bob can append to /srv/team/docs/plan.md, and alice still owns it — not checked yet
bob cannot delete or rename alice's report in /srv/team/reports — not checked yet
alice and bob can put reports into /srv/team/reports, and new reports get the devs group — not checked yet
Others cannot write to docs, reports, plan.md, or alice's new files — not checked yet

Hints

0 of 3 open · they open one at a time

Hint 1

Show the solution after 3 failed checks

Users and permissions · picked for this lab

File permissions

Cheat sheet

$_ — insert into the terminal

ls -l permissions and owner
namei -l /path/to/file where along the path permissions are lost
chmod 640 file owner rw, group r
chmod 600 secret owner only
chmod 755 script executable for everyone
chmod u+x,go-w file symbolic
chmod 2775 dir SGID — a shared group
chmod 1777 dir sticky — only the owner can delete
chown user:grp file see chmod-chown
find / -perm -4000 -type f 2>/dev/null audit SUID

Numbers and symbols

Octal	Permissions	Typically for
`644`	rw-r--r--	regular files
`600`	rw-------	secrets, keys
`755`	rwxr-xr-x	scripts, binaries, directories
`700`	rwx------	private directories
`775`	rwxrwxr-x	a shared group directory
`1777`	rwxrwxrwt	shared with sticky (like /tmp)

bash

ls -l file                        # show permissions/owner
chmod 640 file                    # u=rw g=r o=
chmod u+x,go-w file               # symbolic: +x for owner, remove w from g/o
chmod -R u+rwX dir                # recursive; X = x only for directories/already-executable files
umask                             # the mask for new files (022 → files 644, directories 755)

Special bits

The three special bits and a team's shared directory are covered in Special permission bits.

Bit	On a file	On a directory	Set with
SUID (4xxx)	runs with the file owner's permissions	—	`chmod u+s`
SGID (2xxx)	runs with the group's permissions	new files inherit the directory's group	`chmod g+s`
sticky (1xxx)	—	only the file's owner can delete it (like `/tmp`)	`chmod +t`

bash

ls -l /usr/bin/passwd             # -rwsr-xr-x  ← s = SUID
ls -ld /tmp                       # drwxrwxrwt  ← t = sticky
chmod 2775 /shared                # SGID: a shared directory, files inherit its group
find / -perm -4000 -type f 2>/dev/null   # audit every SUID binary (security)

Permission denied when running a script

The x bit is missing: chmod +x script.sh. Or the file is on a noexec partition (mount | grep noexec, see mount). Or the shebang is wrong.

Can't write to a directory, even though you have w on the file

Creating/deleting/renaming a file depends on permissions on the directory (w+x), not on the file itself. Conversely, you can delete a file with no permissions on it at all, as long as you have w on the directory.

The web server can't read files (403)

nginx runs as www-data — it needs r on the files and x on every directory along the path. namei -l /var/www/site/index.html shows exactly where the permission is missing.

Access should work, but it doesn't

ACLs may be in play (a + in ls -l), or AppArmor (look for apparmor ... DENIED in the journal). Classic permissions alone don't tell the whole story.

An SGID directory: new files have the wrong group

SGID sets the group for new files, but existing ones and files moved in with mv need chgrp -R by hand. Group write access comes from the creator's umask — see Special permission bits.

Danger. chmod -R on system directories (/, /etc, /usr, /var) breaks the permissions that booting and services depend on — for example, the SSH daemon refuses to start if its keys and configs are too open. Scope -R to a specific subtree and check it before restarting anything (ls -ld, namei -l), rather than running it "wider, just in case".

A SUID bit on a binary that can be manipulated in any way (through --help, reading files, or writing) hands a local user code execution with the file owner's permissions. Don't set chmod u+s on scripts and homemade binaries without a clear reason and a review of possible privilege-escalation paths.