Special permissions and ACL¶

Exercise special-permissions-and-acl-annex.pdf · PDF

Here is a riddle. The password hashes live in /etc/shadow, and a normal user cannot even read that file. Yet any user can change their own password with passwd. And changing a password means writing into /etc/shadow. So how does Pau write into a file he cannot open?

The three triplets of Linux permissions (owner, group, others; rwx) cannot explain it. And they cannot solve two real problems at Tramuntana Apps either. Files Pau creates in the dev folder belong to the wrong group, so Marta cannot edit them. And Joan wants Pau to look at the design folder for two weeks without joining the design team. Today you get the extra tools that fix all three.

The card on the door¶

We keep yesterday's picture all page. Every file and folder has a card on its door: who owns it, which group it belongs to, and three lines of rwx for owner, group and others. Today we add three special stamps to that card, and then extra lines for named people.

Everything happens in deb-lab, in the folders /srv/tramuntana/dev, design and admin you built in Linux permissions. Before every test as another user, run whoami; leave with exit.

setuid: borrowing the owner's hands¶

Look at the card of the passwd program:

ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 118168 Apr 19  2025 /usr/bin/passwd

There is an s where the owner's x should be.

The setuid bit (set user ID) makes a program run with the identity of its owner, not of the person who starts it.

passwd belongs to root. So when Pau runs it, the program runs as root and can write in /etc/shadow. Pau borrows root's hands, but only inside that one program, and the program only lets him change his own password. Riddle solved.

A little history¶

The idea came from Dennis Ritchie, co-creator of Unix and of the C language, at Bell Labs. He applied for a patent on 9 July 1973; it was granted on 16 January 1979 (US patent 4,135,240, "Protection of data file contents"). Bell Labs later placed it in the public domain. One bit, and it is still in every Linux and macOS machine.

Hunt them down:

find /usr/bin /usr/sbin -perm -4000 2>/dev/null | sort

On a minimal Debian 13 you get nine programs (a desktop with GNOME shows a few more), all owned by root: chfn, chsh, gpasswd, mount, newgrp, passwd, su, sudo, umount. You know three of them: passwd, su and sudo. Each one needs to touch something only root may touch.

The fourth digit¶

There are three special bits. They form a fourth octal digit, written in front of the three you already know:

Ask for the four digits with stat:

stat -c '%a %A %n' /usr/bin/passwd /tmp

4755 -rwsr-xr-x /usr/bin/passwd
1777 drwxrwxrwt /tmp

4755 is setuid plus 755. 1777 is the sticky bit plus 777.

Small s, capital S¶

The special letter sits on top of the x, so it has to show both things at once:

cd ~/lab && touch x
chmod 4644 x && ls -l x     # -rwSr--r--
chmod 4755 x && ls -l x     # -rwsr-xr-x

setgid: the stamp on new files¶

Yesterday's bug, as it stands now:

sudo ls -l /srv/tramuntana/dev

-rw-rw-r-- 1 pau pau 0 Oct  5 20:52 before.txt

New files take the primary group of whoever creates them, and Pau's primary group is pau. Marta is in dev, not in pau, so for this file she counts as "others": read only. Nobody will remember to run chgrp dev on every file. Set the rule on the folder instead:

sudo chmod g+s /srv/tramuntana/dev      # or: chmod 2770
ls -ld /srv/tramuntana/dev

drwxrws--- 1 root dev 20 Oct  5 20:52 /srv/tramuntana/dev

The setgid bit on a folder makes every file and subfolder created inside it belong to the folder's group.

On the card, setgid is a rubber stamp hanging by the door: every new file gets the department's stamp automatically. After the repair, Pau creates more files:

-rw-rw-r-- 1 pau dev 0 Oct  5 20:52 after.txt
-rw-rw-r-- 1 pau pau 0 Oct  5 20:52 before.txt
drwxrwsr-x 1 pau dev 0 Oct  5 20:52 sub

after.txt belongs to dev with rw- for the group: Marta can edit it now. The new subfolder sub carries the s too, so the rule spreads downwards. Give the other departments the same bit in one go:

sudo chmod 2770 /srv/tramuntana/design /srv/tramuntana/admin

The sticky bit: only cross out your own lines¶

Tramuntana also wants a common folder where all twelve people can drop files. With 777, anyone can delete anyone's file. The folder /tmp has had the same problem for decades, and the same answer:

ls -ld /tmp

drwxrwxrwt 7 root root 140 Oct  5 20:52 /tmp

The sticky bit on a folder means that only the owner of a file (or root) can delete or rename it, even if everybody may write in the folder.

On the card, it is a rule written on the door: "you may only cross out the lines you wrote yourself". Build the common folder:

sudo mkdir /srv/tramuntana/shared
sudo chmod 1777 /srv/tramuntana/shared

Marta creates m.txt in it. Pau tries to delete it:

pau$ rm -f /srv/tramuntana/shared/m.txt
rm: cannot remove '/srv/tramuntana/shared/m.txt': Operation not permitted

Switch the sticky bit off (sudo chmod 777) and Pau deletes it without complaint. Put it back with sudo chmod +t. Notice the message: Operation not permitted, not Permission denied. The sticky rule said no, not the rwx letters.

When three triplets are not enough: ACL¶

Joan, from design, writes to you: "Pau the intern is going to help us with the app icons for two weeks. He must be able to see our folder, but not change anything."

Try to solve it with the card you have. Put Pau in design? Then he can write. Open the folder to "others"? Then everybody reads. There is no fourth line on the card.

An ACL (access control list) adds extra lines to the card of a file or folder: one line per extra named user or named group.

The tools come in the package acl, which may not be installed yet:

sudo apt install acl

Before the ACL, Pau gets ls: cannot open directory '/srv/tramuntana/design': Permission denied. Now add his line and read the whole card:

sudo setfacl -m u:pau:rx /srv/tramuntana/design
sudo getfacl /srv/tramuntana/design

# file: srv/tramuntana/design
# owner: root
# group: design
# flags: -s-
user::rwx
user:pau:r-x
group::rwx
mask::rwx
other::---

And ls -l now shows a + at the end of the string:

drwxrws---+ 1 root design 16 Oct  5 20:52 /srv/tramuntana/design

The + says: "this card has extra lines; ask getfacl".

Every file has its own card¶

Pau tests his new access:

pau$ ls /srv/tramuntana/design
logo.txt
pau$ cat /srv/tramuntana/design/logo.txt
cat: /srv/tramuntana/design/logo.txt: Permission denied

He sees the list but cannot open the file. Why? The folder's card lets him in, but logo.txt has its own card (-rw-rw---- joan design), and Pau is not on it. Add him there too:

sudo setfacl -m u:pau:r /srv/tramuntana/design/logo.txt

Now cat prints logo. And touch p.txt in the folder still fails: he has no w.

Default ACL: lines for future files¶

Doing that for every new file is hopeless. A default ACL on the folder is copied onto every file created inside it:

sudo setfacl -d -m u:pau:rx /srv/tramuntana/design

Joan creates new.txt. Its card:

# owner: joan
# group: design
user::rw-
user:pau:r-x    #effective:r--
group::rwx  #effective:rw-
mask::rw-
other::---

Pau's line arrived by itself. But look at #effective:r--.

The mask: the ceiling¶

The mask is the ceiling for every extra ACL line and for the group: a line can never give more than the mask allows. getfacl shows the real result as #effective:.

new.txt was created without x, so its mask is rw-. Pau's line says r-x, but under a ceiling of rw- only r-- is left. He can read every new file and change none: exactly what Joan asked for.

flowchart LR
    L["<b>Pau's line</b><br>r-x"] --> M{"<b>Mask</b><br>rw-<br>the ceiling"}
    M --> E["<b>Effective</b><br>r--<br>only what both allow"]

There is one trap. When a file has an ACL, the middle triplet of ls -l shows the mask, not the group. So a careless chmod g-rwx lowers the ceiling and switches off every extra line at once:

sudo chmod g-rwx /srv/tramuntana/design/logo.txt
sudo getfacl /srv/tramuntana/design/logo.txt     # mask::---  and  user:pau:r--  #effective:---
sudo setfacl -m m::rw /srv/tramuntana/design/logo.txt   # repair: raise the ceiling again

Pau's line was still there; the ceiling had dropped to the floor.

Key takeaways¶

• setuid (4, s in the owner's x) makes a program run as its owner: that is how passwd writes in /etc/shadow. Keep a list of setuid programs.
• setgid (2, s in the group's x) on a folder gives every new file the folder's group: the fix for the department folders.
• The sticky bit (1, t in the others' x) lets only a file's owner (or root) delete it: the rule of /tmp and of the common folder.
• A capital S or T means the special bit is set without x: almost always a mistake.
• An ACL adds lines for named users and groups (setfacl -m, getfacl); a + in ls -l tells you it exists. Each file has its own card; a default ACL covers future files.
• The mask is the ceiling of every extra line: #effective: shows what is really allowed.

Quick check¶

You met one more setuid program today without noticing: sudo. Next: how to hand out root's power in small pieces, one command at a time, with sudo and least privilege.