Permissions

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.

Right, so you’ve mastered the basic chmod and chown incantations. You feel pretty good about yourself, and you should. But then you hit a wall. What if you need to give two different users two different sets of permissions on the same file? The standard Unix permissions model looks at you, shrugs, and says, “One owner, one group, and the rest. That’s all you get. Take it or leave it.”

Right, let’s talk about one of the most brilliantly confusing and misunderstood parts of Unix file permissions: the directory execute bit. You’ve probably wrapped your head around read and write for files, but directories? They play by a different set of rules, and the execute permission is the star of this particular show. It’s not about running a directory like a script (thankfully, that’s not a thing), it’s about granting the key to the kingdom: access.

Right, let’s get our hands dirty with ls -l. This is where you stop just seeing files and start seeing files. It’s the decoder ring for the secret language of permissions, ownership, and all the other metadata the system uses to decide if you’re allowed to do what you’re trying to do. Running it in a directory gives you that glorious, slightly intimidating, multi-column output. Let’s break down what each piece of this digital dossier actually means.

Right, let’s talk about umask. This is one of those concepts that sounds more intimidating than it is, mostly because it works by subtracting permissions. It feels backwards, because it is. Some committee in the 70s probably thought this was clever, and we’ve been stuck with it ever since. Think of it this way: when a process, like your shell’s touch or mkdir, creates a new file or directory, it asks the system for a set of “default” permissions. For files, this is usually 666 (read and write for everyone). For directories, it’s 777 (read, write, and execute for everyone). Let that sink in for a second. If we actually got those defaults, any file you create would be instantly writable by any other user on the system. That’s a security nightmare straight out of the gate.

Alright, let’s talk about chmod. This is the command that lets you tell the system who gets to do what to a file. It’s the digital equivalent of a bouncer at a very exclusive club, checking a list before letting anyone in. And just like a bouncer, if you give it the wrong instructions, you’re going to have a bad time. You can use chmod in two main ways: the quick, powerful, but slightly cryptic octal mode (like 755) and the more verbose but intuitive symbolic mode (like u+x). We’re going to master both.

Right, let’s get into the guts of file permissions. You’ve probably seen the cryptic rwxrwxr-x and wondered, “Is this a license plate or a security system?” It’s a bit of both. At its core, it’s a brilliantly simple, if occasionally infuriating, way to control who can do what to your files. We’re going to crack it open. The first thing to wrap your head around is that these three little letters mean something completely different depending on whether they’re on a file or a directory. This is the single biggest source of confusion, so we’ll tackle it head-on.

Right, let’s talk about the thing that will inevitably drive you to drink at least once: file permissions. It’s the system’s way of playing bouncer at the club of your filesystem, deciding who gets in and what they can do once they’re inside. It seems archaic until you get a crypto-locker ransomware because a directory was world-writable, and then it seems like the most brilliant idea ever conceived. The entire model rests on three simple, slightly anthropomorphic concepts: the User (u), the Group (g), and the Other (o). Don’t overthink the names; they’re brutally literal.