Linux file permissions control who can read, write, and execute files, but some tasks require more than standard permissions. This is where special permissions such as SUID, SGID, and the sticky bit come into play. They provide controlled elevated access, simplify collaboration, and help protect shared directories when used correctly.

If you've ever run ls -l and noticed an unexpected s or t instead of an x, you're not alone. In this guide, you'll learn what these special permissions mean, how they work, when to use them, and how to configure them safely with practical examples that are easy to follow.

Regular Linux permissions cover three things: who owns a file, what group it belongs to, and what everyone else can do with it. Special permissions add a fourth layer on top of that, one that changes how a file or directory behaves rather than just who can touch it.

There are three special permissions: SUID (Set User ID), SGID (Set Group ID), and the sticky bit. SUID makes a program run with the identity of its owner instead of the person running it. SGID does something similar for group ownership, and on directories it makes new files inherit the parent directory's group automatically. The sticky bit doesn't touch execution at all, it just controls who's allowed to delete files inside a shared directory.

You've almost certainly used SUID already without noticing it. Every time you run passwd to change your own password, that binary is running as root behind the scenes, because it needs root access to edit /etc/shadow, and that only works because of SUID. This ties directly into the broader idea of how Linux treats different file types, since special permissions behave differently depending on whether you're looking at a regular file or a directory.

Special permissions can be set with either the symbolic method or the numeric method, the same two approaches you'd use for regular chmod operations.

The numeric method adds a fourth digit in front of the usual three. SUID is 4, SGID is 2, sticky bit is 1, and you can combine them by adding the values together, so 6 sets both SUID and SGID at once.

Before changing anything, it helps to know how to read what's already there. The passwd binary is the classic example.

Notice the lowercase s sitting where the execute bit for the owner would normally be. That's SUID, telling you passwd always runs as root no matter who launches it.

Say you have a monitoring script that needs to read a log file only root can access.

This is where SGID earns its keep. Set it on a directory and every new file created inside inherits the directory's group automatically.

Any folder where multiple users can write files but shouldn't be able to delete each other's work needs this.

That lowercase t at the end is your confirmation. This is exactly how /tmp works on every Linux system you've ever logged into.

You don't have to set these one at a time. A shared department folder often needs both group inheritance and delete protection together.

The 3 comes from adding SGID (2) and sticky bit (1). Files created here inherit the shared group, and only the file's own creator can remove it later.

If a security scan flags a binary with SUID that shouldn't have it, pulling it off is a one-liner.

This is the command you'll actually run during a security review, and one worth memorizing.

Read this list carefully after every new deployment. If find turns up something you don't recognize on that list, treat it as a red flag and investigate before anything else.

A small dev team shares a deployment directory on a staging server. Without SGID, every deploy from a different team member changes the file's group and breaks the next person's write access.

After this, every file any team member drops into that directory keeps the devteam group automatically, no more manually fixing ownership after every deploy. If you haven't set up chgrp based group ownership before, this is a good place to start practicing it.

An internal file server lets an entire department drop files into one shared folder. Without the sticky bit, anyone in that group could delete anyone else's uploads by accident, or on purpose.

This one trips up a lot of people moving from a course into real servers. Setting SUID on a bash script does not give it root privileges, even though the permission bit shows correctly.

Set up a specific sudoers entry instead if the script genuinely needs elevated access. Our sudo configuration guide walks through doing this safely without opening the door wider than it needs to be.

Sometimes you want the raw permission number rather than reading symbols off the screen, especially when scripting a compliance check.

The leading 4 confirms SUID before you even look at the rest of the number.

Without SUID, a huge chunk of ordinary Linux workflows would break outright. Regular users couldn't change their own passwords, mount removable drives, or ping a remote host, because all of those actions genuinely need root level access for one narrow operation. SUID lets that access exist only where it's needed instead of handing everyone root permanently.

On the flip side, an unmonitored SUID binary is one of the oldest privilege escalation tricks in the book, and it's still how a surprising number of real breaches happen on servers that skip regular audits. Running that find / -xdev -perm -4000 sweep after every patch cycle or new package install isn't paranoia, it's basic hygiene, similar to how the official chmod manual documents these bits as deliberate, security relevant behavior rather than convenience flags. It's worth folding this check into a wider server hardening routine rather than treating it as a one-time task.

LinuxTeck - A Complete Linux Learning Blog
From your first terminal command to advanced sysadmin skills, every guide here is written in plain English with real examples you can run right now.