Sgid

Right, let’s talk about the dark side of these superpowers. Because while SUID, SGID, and the sticky bit are incredibly useful, they are also a massive, blinking, neon-lit attack surface. They’re like giving a normal user a key to the server room: sometimes it’s necessary, but you’d better be damn sure you know who has the key and that the lock is un-pickable. The core problem is privilege escalation. These bits let a user-run process do things the user themselves couldn’t. If an attacker can compromise that process, they don’t just get your user’s privileges—they get the privileges of the file’s owner (for SUID) or group (for SGID). This is the golden ticket. This is how you go from “some random user account” to “root.”

Right, so you’ve got a system, and you want to know what’s on it that has the potential to elevate your privileges. The most straightforward way to do this is by asking the filesystem itself. The find command is our go-to tool for this; it’s the grumpy, hyper-efficient librarian who knows exactly where every book is and isn’t afraid to tell you. The magic lies in the -perm (permissions) test. We’re looking for two specific permission sets: the SUID bit (4000) and the SGID bit (2000). The numbers might seem arbitrary, but they’re not. Think of the standard 755 permissions (user, group, other). These special bits live in the prefix to that number. A 4755 means “this has the permissions 755 and the SUID bit is set.”

Right, so you’ve met the special permissions: that weird SUID, SGID, and Sticky Bit trio. You can set them with the symbolic method (u+s, g+s, +t), but let’s be honest: when you’re scripting or when the command just feels right in your fingers, you go octal. It’s more precise, and it looks like digital wizardry to the uninitiated. We’re about to become initiates. The octal method for chmod is an 4-digit code. You’ve used the 3-digit one for standard permissions (755, 644, etc.). The special permission digit is the leading fourth digit.

Right, so you’ve got /tmp. A glorious, chaotic free-for-all where every user and their cron job can create files. It’s the digital equivalent of a public park after a concert. The problem is, if it’s world-writable (which it has to be), what’s stopping User A from waltzing in and deleting User B’s precious temporary file? Or, more nefariously, replacing a script User B is about to execute? Enter the Sticky Bit. This is the old, grumpy bouncer of the directory world. It doesn’t care who creates a file—the bouncer lets anyone into the club. Its one job is to make sure you can’t mess with someone else’s stuff once it’s in there. The name is a historical artifact; it was originally designed to “stick” a program’s executable image in swap space after it finished to make it load faster. That use is long dead, but the name and its modern, far more important purpose on directories lives on.

Right, so you’ve got SUID figured out for files. It’s weird, but it makes a sort of twisted sense. Now let’s talk about its cousin for directories, SGID. This is where things get genuinely useful instead of just dangerously interesting. When you set the SGID bit on a directory (chmod g+s), you’re changing the rules of the game for any new file or directory created within it. Here’s the rule: any new item created inside an SGID directory will have its group ownership set to the group owner of the parent directory, not the primary group of the user who created it.

Right, so you’ve wrapped your head around SUID, which makes a process run as the user who owns the file. SGID is its slightly less famous, but arguably more useful, cousin. When you set the SGID bit on an executable file, it doesn’t change the user ID of the process—it changes the group ID. The process runs with the effective group permissions of the group that owns the file, not your primary group or any of your supplementary groups.

Right, let’s talk about SUID. It’s one of those things that sounds complicated but is actually a beautifully simple, terrifyingly powerful hack. The acronym stands for Set User ID, and its purpose is to temporarily and selectively promote a user’s privileges. Think of it as a temporary VIP pass for a specific program. Normally, when you run a program, it runs with your permissions. You can’t delete other users’ files because the process is wearing your identity badge. SUID flips this script. When you run an SUID program, it doesn’t run as you; it runs as the user who owns the executable file. This is almost always root.