Special Permission Bits

The permission model from the last two files — read, write, execute, across owner, group, and other — covers the vast majority of what you’ll ever need. But there are three situations it can’t express on its own: running a program with someone else’s privileges, keeping a consistent group across every file in a shared directory, and preventing one user from deleting another’s files in a directory they both have write access to. Three special bits solve exactly these three problems.

setuid: Run As The File’s Owner, Not The User Running It

Normally, a program runs with the privileges of whoever launched it. setuid (“set user ID”) changes that — a program with the setuid bit set runs with the privileges of the file’s owner, regardless of who actually executes it.

The clearest example already exists on your system: the passwd command, which lets ordinary users change their own password. Changing a password means writing to /etc/shadow, a file ordinary users have no permission to touch directly. passwd is owned by root and has the setuid bit set — so when you run passwd, it briefly runs with root’s privileges, does the one specific thing it’s designed to do, and exits. You get just enough elevated access to accomplish that one task, without ever having broader root access yourself.

You’ll see setuid represented as an s in place of the owner’s execute bit:

-rwsr-xr-x 1 root root 68208 Jan 15 10:03 /usr/bin/passwd

That s where you’d expect owner execute (x) is the visual signal. Set it with chmod using either notation:

sudo chmod u+s program
sudo chmod 4755 program

In numeric mode, setuid is represented by a leading fourth digit — 4 — placed before the usual three.

setgid: Inherit The Group, Not Just The Owner’s Privileges

setgid (“set group ID”) behaves similarly to setuid but for the group instead of the owner, and it means something genuinely different depending on whether it’s applied to a file or a directory.

On an executable file, setgid works like setuid’s sibling: the program runs with the privileges of the file’s group, rather than the group of whoever ran it.

On a directory, setgid does something more commonly useful day-to-day: any new file or subdirectory created inside automatically inherits the directory’s group, rather than the primary group of whoever created it. This is the piece that solves a real, recurring problem — keeping a shared directory’s files consistently owned by the right group without everyone needing to remember to set it manually every time.

You’ll see setgid represented as an s in the group’s execute position:

drwxrwsr-x 2 alice developers 4096 Jan 15 10:03 shared-project/

Set it the same way as setuid, targeting the group instead:

sudo chmod g+s shared-project/
sudo chmod 2775 shared-project/

The leading digit for setgid alone is 2.

The Sticky Bit: Protect Files From Everyone But Their Owner

The sticky bit solves a different problem entirely, and it only really matters on directories. Recall from the Permission Model file: deleting a file is really an operation on the directory’s write permission, not the file’s own permissions. That means in a directory where multiple people have write access, any of them can delete any file inside — including files they don’t own — as an unavoidable side effect of everyone needing to create files there in the first place.

The sticky bit closes that gap: in a directory with the sticky bit set, a user can only delete or rename files they themselves own, even though everyone with write access can still create new files there.

The clearest real-world example is one you already know: /tmp. Every user on the system needs to write temporary files there, but nobody should be able to delete someone else’s temp files just because they happen to share write access to the same directory. Check it yourself:

ls -ld /tmp

You’ll see something like:

drwxrwxrwt 13 root root 4096 Jan 15 10:03 /tmp

Notice the final character is t, not x — that’s the sticky bit, shown in the “other” execute position. Set it the same way as the other two:

sudo chmod +t shared-uploads/
sudo chmod 1777 shared-uploads/

The leading digit for the sticky bit alone is 1.

Recognizing All Three At A Glance

Since each occupies its own distinct position in the permission string, you can combine them freely, and their numeric values add together just like the regular rwx digits did:

chmod 3775 shared-project/

3 here is 2 + 1 — setgid and sticky bit together — a genuinely common combination for a shared team directory: setgid keeps every new file consistently owned by the team’s group, and the sticky bit stops any one team member from deleting another’s files by accident.

Real-World Example: A Shared Team Directory

Put the last two special bits together to build something you’d realistically set up as a sysadmin: a directory where a whole team can collaborate, files consistently belong to the team’s group, and nobody can accidentally wipe out someone else’s work.

sudo mkdir /srv/team-project
sudo chgrp developers /srv/team-project
sudo chmod 3775 /srv/team-project

Walk through what each piece accomplishes:

• chgrp developers sets the directory’s group, so anything created inside starts from the right baseline.
• 3775 breaks down as: 3 (setgid + sticky), 7 (owner: full access), 7 (group: full access), 5 (other: read and execute, but not write).

Check the result:

ls -ld /srv/team-project

drwxrwsr-t 2 root developers 4096 Jan 15 10:03 /srv/team-project

Any member of the developers group can now create files here, every file created automatically belongs to the developers group regardless of who created it (setgid), and no one — other than the file’s actual creator or root — can delete someone else’s file inside it (sticky bit). This is a genuinely common real pattern on shared servers, and now you know exactly what each piece of that permission string is doing and why.

sudo rm -rf /srv/team-project

Clean up once you’ve confirmed the behavior for yourself — there’s no need to leave a test directory sitting around afterward.

What’s Next

That closes out permissions — you can read them, change them, and now understand the three special cases layered on top of the basic model. The next section moves to the accounts these permissions actually apply to: users and groups, how they’re defined on the system, and how privilege escalation with sudo — which you’ve now used a few times without a full explanation — actually works underneath.