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.

Think of it like this: [special][user][group][other]

That first digit is where the magic (or mayhem) happens:

  • 4 is for SUID (Set User ID)
  • 2 is for SGID (Set Group ID)
  • 1 is for the Sticky Bit
  • You can also add them together: 7 (4+2+1) would set all three, which is a terrifying prospect you should almost never entertain.

How the Octal Digit Works

Let’s make this concrete. You have a file. You want to set it to read/write/execute for the owner, read/execute for group, and nothing for others. That’s 750. To add SUID to that, you slap a 4 on the front, making it 4750.

chmod 4750 my_program

Why 4750 and not 7504? Because the bits are stored in the filesystem in that order. The leading digit controls the special attributes, and the subsequent three control the standard rwx ones. The command is designed to reflect the actual underlying data structure. It’s not arbitrary; it’s literal.

SUID in Action: The Classic Example

Let’s use the quintessential example: passwd. The /usr/bin/passwd binary needs to modify /etc/shadow, which is root-owned and not writable by mere mortals. So, it runs with the authority of its owner (root) instead of the user who executed it.

ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 63960 Feb  7  2023 /usr/bin/passwd

See that s in the user’s execute permission spot? That’s the SUID bit in action. The octal permission that creates this is 4755. Let’s recreate it on a dummy file:

touch my_suid_demo
chmod 4755 my_suid_demo
ls -l my_suid_demo
-rwsr-xr-x 1 user user 0 Feb 28 14:22 my_suid_demo

Crucial Pitfall: Notice the file must actually be executable for the SUID bit to mean anything. If it’s not executable, you’ll see a capital S instead of a lowercase s (rwsr-xr-x vs. rwSr--r--). This is the system’s way of yelling, “Hey, you set the SUID bit, but this thing can’t even run! This is probably a mistake!” And it’s almost always right.

SGID: For Files and (More Useful) Directories

The SGID bit (2xxx) has a dual personality. On a file, it behaves like SUID but for the group; the program runs with the effective permissions of the file’s group.

Its superpower is on a directory. This is where you’ll use it 99% of the time. When SGID is set on a directory, any new file or subdirectory created within it automatically inherits the group ownership of the parent directory—not the primary group of the user who created it. This is absolutely vital for collaborative workspaces.

mkdir team_project
sudo chown :developers team_project # Set the group owner to 'developers'
chmod 2775 team_project             # SGID + rwx for owner/group, rx for others
ls -ld team_project
drwxrwsr-x 2 user developers 4096 Feb 28 14:30 team_project

Now, any file created in team_project by anyone will be owned by the group developers. No more “wait, who owns this file and why can’t my teammate edit it?” nonsense.

The Sticky Bit: Taming /tmp

The Sticky Bit (1xxx) on a file was a historical relic. On a modern directory, it’s a brilliant safety feature. It dictates that only the owner of a file (or root) can delete or rename that file within the directory. The classic example is /tmp. Everyone needs to write there, but you don’t want some joker deleting your vim swap file while you’re using it.

ls -ld /tmp
drwxrwxrwt 15 root root 4096 Feb 28 14:35 /tmp

See the t at the end of the permissions? That’s the Sticky Bit. Let’s make our own shared, but safe, directory:

mkdir public_upload
chmod 1777 public_upload # Sticky + full permissions for everyone
ls -ld public_upload
drwxrwxrwt 2 user user 4096 Feb 28 14:40 public_upload

Now, anyone can create a file in public_upload, but I can’t delete your files and you can’t delete mine. The system politely tells you to get lost if you try (Operation not permitted).

Best Practices and The Cardinal Sin

  1. SUID is a Liability: Every SUID binary is a potential path to privilege escalation. Your attack surface is the sum of all SUID/SGID programs on your system. Audit them with find / -type f -perm /4000 and find / -type f -perm /2000. Question every single one. Do you really need that custom script to be SUID? (Spoiler: no, you almost never do. Use group permissions or sudo instead).

  2. SGID for Directories is Your Friend: This is the correct, elegant way to handle group collaboration. Use it liberally.

  3. The Capital S Problem: Always remember that chmod 4644 my_file is mostly pointless. The s bits only have meaning if the underlying execute permission is also set for the user or group. If you see a capital S or T in an ls -l listing, stop and ask yourself what you were actually trying to accomplish. You probably meant to chmod 4744 but should have done 4755.