Day 4 - Special Permissions and ACLs: SetUID · SetGID · Sticky bit · getfacl/setfacl

📌 Key Takeaways

• Special permissions are a fourth octal digit placed in front of the 9 bits — SetUID=4, SetGID=2, Sticky=1.
• SetUID runs a program with the owner's privileges no matter who executes it (passwd=4755). The biggest privilege-escalation risk point.
• A SetGID directory automatically passes down its group to files created inside it. The key tool for group collaboration.
• Sticky bit prevents deleting other people's files in a shared directory. /tmp = 1777.
• ACLs go beyond the three-slot limit of owner-group-other. The + at the end of ls -l is the signal of their presence, and the mask is the upper bound.

Special Permissions — The Fourth Octal Digit

There are problems the 9 bits alone cannot solve. How does a regular user modify /etc/shadow, which only root can write? /tmp is writable by everyone, so why can't you delete other people's files? What if you want to give different permissions to just two people?

• When you write four digits of octal in chmod, the leading digit is the special permission. The weights are SetUID=4, SetGID=2, Sticky=1.

chmod 4755 program     # SetUID + rwxr-xr-x
chmod 2755 shareddir   # SetGID + rwxr-xr-x
chmod 1777 /tmp        # Sticky + rwxrwxrwx
chmod 6755 program     # SetUID+SetGID(4+2)

Special permissions appear overlaid on the x slot of the 9-bit permission display. SetUID is shown in the owner's x slot, SetGID in the group's x slot, and Sticky in the other's x slot. If x was originally present it shows as lowercase (s/t), and if x is absent it shows as uppercase (S/T). Uppercase is a warning sign that "the special permission is on but there is no execute permission, so it is effectively meaningless."

SetUID — Run with the Owner's Privileges

An executable file with SetUID set runs with the privileges of that file's owner, no matter who executes it. The representative example is /usr/bin/passwd.

ls -l /usr/bin/passwd
# -rwsr-xr-x 1 root root ... /usr/bin/passwd
#    └ s in the owner's x slot = SetUID

The passwd command must modify /etc/shadow, which only root can write (permissions 000 or 400). How can a regular user alice change her own password? Because passwd has SetUID set and runs with the owner's (root's) privileges, the moment alice runs it, that process can modify shadow with root privileges. Without SetUID, a regular user could not even change their own password. That is the reason SetUID exists.

⚠️ Trap: SetUID is the biggest security threat point. If a program with SetUID has a vulnerability, an attacker can seize root privileges (privilege escalation). In particular, setting SetUID on shell scripts or general-purpose tools like vi and cp is absolutely forbidden (if cp had root SetUID, anyone could overwrite any file). That is why the Linux kernel ignores SetUID on shell scripts altogether. The command for regularly checking whether the system has unintended SetUID files appears on the exam:

# Search for all SetUID files (the security audit standard)
find / -perm -4000 -type f 2>/dev/null
# Search for SetGID files
find / -perm -2000 -type f 2>/dev/null
# Both SetUID + SetGID
find / -perm /6000 -type f 2>/dev/null

SetGID — Run with Group Privileges + Directory Group Inheritance

SetGID works in two different contexts.

• Set on an executable file: runs with the privileges of the owning group (the group version of SetUID).
• Set on a directory (the exam key): the owning group of new files and subdirectories created inside automatically becomes that directory's group.
• Normally the file creator's primary group becomes the owning group, but in a SetGID directory the directory's group is inherited.

mkdir /project && chgrp dev /project && chmod 2775 /project
# Now whoever creates a file inside /project, the group is always dev

A SetGID directory is the key tool for group collaboration. When several people collaborate in one directory, if the group of each person's files differs, they block each other's access. If you set SetGID, all files get a common group, and if you grant group-write (g+w) to that group, the whole team can freely edit each other's files. In Day 3 we said "the group of a new file is the creator's primary group," and the SetGID directory is exactly that exception.

Sticky bit — Deletion Protection for Shared Directories

• In Day 3 we said, "if you have w permission on a directory, you can delete files in it (even if you are not the owner)."
• In a directory everyone uses, like /tmp, this is a disaster — anyone could delete someone else's temporary files. The sticky bit prevents this.

ls -ld /tmp
# drwxrwxrwt 10 root root ... /tmp
#         └ t in the other's x slot = Sticky

In a directory with the sticky bit set, even if you have w permission on the directory, only the file's owner (or the directory's owner, or root) can delete or rename that file. This is why /tmp is 1777 (rwxrwxrwt). Everyone can create files (shared), but cannot delete others' files (protected). Without the sticky bit, anyone could delete others' files in /tmp, causing security and stability problems.

⚠️ Trap: Today the sticky bit has meaning only on directories. In the past (early Unix), it was set on executable files to "keep the program resident in memory/swap" (the origin of the name "sticky"), but modern kernels ignore sticky on files. On the exam, "the sticky bit is used to keep a file resident in memory" is a wrong answer by modern standards.

# Try it yourself — observe and experiment with special permissions
ls -l /usr/bin/passwd /usr/bin/sudo      # check SetUID (s)
ls -ld /tmp /var/tmp                      # check Sticky (t)
mkdir testdir && chmod 2775 testdir && ls -ld testdir   # check SetGID (s)
touch testdir/a && ls -l testdir/a        # observe group inheritance

In the 1990s, there was a university server where the sticky bit was missing from /tmp. When one student deleted another student's temporary compile files as a prank, builds failed one after another, and more seriously, a "symlink attack" became possible in which someone deletes a lock file that some program created in /tmp or swaps it for a symbolic link. After the sticky bit was introduced, this attack surface closed. That is why every shared writable directory (/tmp, /var/tmp) must have the sticky bit set.

ACL — Beyond the Three Slots of owner/group/other

• The fundamental limit of standard permissions: for one file, you can specify only one owner and only one group.
• A finer-grained requirement such as "rw for alice, r for bob, rw for the dev group, block everyone else" cannot be expressed in three slots.
• ACL (Access Control List) solves this limit by attaching an additional "list of per-user and per-group permission entries" to each file.

getfacl file.txt          # view the ACL
setfacl -m u:bob:r file.txt        # grant read to bob (-m = modify)
setfacl -m g:dev:rw file.txt       # read/write for the dev group
setfacl -x u:bob file.txt          # remove bob's ACL entry (-x)
setfacl -b file.txt                # remove all ACLs (-b = remove all)
setfacl -m d:u:bob:rw dir          # default ACL — inherited by children
setfacl -R -m u:bob:rw dir         # apply recursively

The output structure of getfacl:

# file: file.txt
# owner: alice
# group: dev
user::rw-          ← owner (standard owner)
user:bob:r--       ← bob's individual ACL
group::rw-         ← owning group (standard group)
group:audit:r--    ← audit group's individual ACL
mask::rw-          ← mask (upper bound of ACL permissions)
other::r--         ← other (standard other)

For a file with an ACL set, a + sign is attached to the end of the permissions in ls -l (-rw-rwxr--+). Seeing this + is a signal that "this file has an ACL in addition to the standard permissions." On the exam, the answer to "what is the + at the end of the permission display?" is the indicator of an ACL's presence.

The ACL mask is the tricky point. The mask is "the upper bound of the permissions that named users/groups (ACL entries with a name attached) and the owning group can have." Even if you gave bob rwx with setfacl -m u:bob:rwx, if the mask is r--, bob's effective permission stops at r. getfacl attaches an #effective: comment to entries trimmed by the mask to show the actual permissions. Changing the group permissions with chmod actually changes the mask, so you must be careful when applying chmod to a file with an ACL.

Even with an ACL, the standard owner/group/other permissions still exist, and there is an access decision order. ① If the user is the owner, the owner permissions apply → ② if they are in a named user ACL, that entry applies → ③ if they are in the owning group or a named group ACL, one of those applies (limited by the mask) → ④ if none match, other applies. Problems of the "I gave an ACL but the permission doesn't take effect" type are usually cases where the mask is trimming it, or where the user is the owner so the owner permissions apply first.

A company's audit team (the audit group) needed to be able to "only read" a specific log directory. But that directory was already owned by the ops group and the group slot of the standard permissions was occupied by ops. A second group could not be put in with standard permissions, so they added a read + directory-entry ACL for the audit group with setfacl -m g:audit:rX -R /var/log/app. It is a typical case where an ACL solved "different permissions for two groups," which was impossible with the standard permission model. (Uppercase X grants x only to directories/executable files, as seen in Day 3.)

# Try it yourself — ACL experiment
touch acltest.txt
setfacl -m u:nobody:rw acltest.txt
ls -l acltest.txt                  # confirm the + at the end
getfacl acltest.txt                # check the ACL entries and mask
setfacl -b acltest.txt && ls -l acltest.txt   # the + disappears after removal

Special Permissions and ACL Cheat Sheet

• If you can instantly answer /tmp = 1777, passwd = 4755 (rwsr-xr-x), and SetGID directory = group inheritance, you have grasped the essentials.

📖 Glossary

• Special permissions : The fourth octal digit placed before the 9 bits. SetUID (4) · SetGID (2) · Sticky (1).
• SetUID : A bit that makes a program run with the file owner's privileges whoever runs it. s in the owner's x slot.
• SetGID (file) : A bit that makes a program run with the owning group's privileges when executed.
• SetGID (directory) : A bit that makes files created inside inherit the directory's group. The key to collaboration directories.
• Sticky bit : A bit that restricts a shared directory so that you can delete only your own files. The reason /tmp is 1777.
• Uppercase S/T : A warning indicator that the special permission is on but that slot has no execute permission.
• find / -perm -4000 : The standard security audit command that sweeps the system's SetUID files.
• Privilege escalation : An attack that rides a vulnerability in a SetUID program to seize root privileges.
• Symlink attack : An attack that swaps a file in a shared directory for a symbolic link. The sticky bit blocks it.
• ACL : An extended permission list that attaches individual per-user and per-group permission entries to each file.
• getfacl / setfacl : The command that views ACLs and the command that sets/deletes them (-m add, -x delete an entry, -b delete all).
• mask : The upper bound of the permissions that named ACL entries and the owning group can have. Because of it, permissions you granted sometimes do not take effect.
• + in ls -l : An indicator that the file has an ACL.
• Default ACL : An ACL set on a directory with setfacl -m d:... that is inherited by newly created children.