Special permissions (setuid, setgid, sticky bit) in Linux CLI - Deep Dive

Overview - Special permissions (setuid, setgid, sticky bit)

What is it?

Special permissions in Linux are extra settings that change how files and directories behave. They include setuid, setgid, and the sticky bit. These permissions control who can run files with certain privileges or who can delete files in shared directories. They help manage security and access in multi-user systems.

Why it matters

Without special permissions, users might not be able to safely share files or run programs that need extra rights. For example, some programs need to run as the owner to work correctly. Without these permissions, users could accidentally or maliciously delete or change files they shouldn't. Special permissions keep systems secure and organized.

Where it fits

Before learning special permissions, you should understand basic Linux file permissions like read, write, and execute. After this, you can explore advanced security topics like Access Control Lists (ACLs) and Linux capabilities for finer control.

Mental Model

Core Idea

Special permissions are like secret badges that let files or directories act with extra powers beyond normal user rights.

Think of it like...

Imagine a shared office where some doors have special locks: setuid is like a key that lets you enter as the manager, setgid is like a badge that lets you join a team meeting, and the sticky bit is like a rule that only lets you remove your own papers from a shared desk.

┌───────────────┐
│ File/Directory│
├───────────────┤
│ Normal perms  │
│ (rwx for user,│
│ group, others)│
├───────────────┤
│ Special perms │
│ ┌───────────┐ │
│ │ setuid    │ │
│ │ setgid    │ │
│ │ sticky bit│ │
│ └───────────┘ │
└───────────────┘

Build-Up - 8 Steps

1

Foundation

Basic Linux File Permissions

Concept: Learn the standard read, write, and execute permissions for user, group, and others.

In Linux, every file and directory has permissions for three types of users: the owner (user), the group, and everyone else (others). Each can have read (r), write (w), and execute (x) permissions. For example, 'rwxr-xr--' means the owner can read, write, and execute; the group can read and execute; others can only read.

Result

You understand how to read and interpret basic permissions like rwxr-xr--.

Understanding basic permissions is essential because special permissions build on top of these standard rights.

2

Foundation

Understanding Permission Representation

Concept: Learn how permissions are shown in commands like ls -l and how to change them with chmod.

The command 'ls -l' shows permissions as a string of 10 characters. The first character shows the file type, and the next nine show permissions in sets of three for user, group, and others. You can change permissions using 'chmod' with symbolic (e.g., u+x) or numeric (e.g., 755) modes.

Result

You can read permission strings and modify permissions using chmod.

Knowing how to read and set permissions is the foundation for understanding how special permissions modify these strings and behaviors.

3

Intermediate

Setuid Permission Explained

🤔Before reading on: do you think setuid lets anyone run a program as root or just as the file owner? Commit to your answer.

Concept: Setuid lets users run an executable with the file owner's permissions temporarily.

When setuid is set on an executable, anyone running it temporarily gains the file owner's permissions during execution. For example, if a program owned by root has setuid, users can run it with root privileges. This is shown as an 's' in the user execute position in 'ls -l' (e.g., '-rwsr-xr-x').

Result

Programs with setuid run with the owner's rights, allowing controlled privilege escalation.

Understanding setuid is key to managing programs that need higher privileges without giving users full access.

4

Intermediate

Setgid Permission on Files and Directories

🤔Before reading on: does setgid on a directory affect file ownership or just permissions? Commit to your answer.

Concept: Setgid on files runs them with the group owner's permissions; on directories, it forces new files to inherit the directory's group.

For files, setgid works like setuid but for group permissions, shown as 's' in the group execute position (e.g., '-rwxr-sr-x'). For directories, setgid makes new files and subdirectories inherit the directory's group, helping keep group collaboration organized.

Result

Setgid helps manage group access and ownership in shared environments.

Knowing setgid's dual role helps maintain consistent group permissions in collaborative directories.

5

Intermediate

Sticky Bit on Directories

Concept: Sticky bit restricts file deletion inside a directory to only the file owner or root.

When the sticky bit is set on a directory, users can only delete or rename files they own, even if others have write permission on the directory. This is common on shared directories like /tmp. It appears as a 't' in the others execute position (e.g., 'drwxrwxrwt').

Result

Sticky bit protects files in shared directories from being deleted by others.

Sticky bit is crucial for safe multi-user environments where many users share write access.

6

Advanced

Setting and Removing Special Permissions

🤔Before reading on: do you think numeric chmod codes can set special permissions or only symbolic modes? Commit to your answer.

Concept: Special permissions can be set or removed using both symbolic and numeric chmod modes.

You can set setuid, setgid, and sticky bit using chmod. Symbolic examples: 'chmod u+s file' sets setuid; 'chmod g+s dir' sets setgid; 'chmod +t dir' sets sticky bit. Numeric codes use a leading digit: 4 for setuid, 2 for setgid, 1 for sticky bit. For example, 'chmod 4755 file' sets setuid with rwxr-xr-x permissions.

Result

You can control special permissions precisely using chmod commands.

Knowing both symbolic and numeric methods gives flexibility and precision in permission management.

7

Advanced

Security Risks and Best Practices

🤔Before reading on: do you think setting setuid on any executable is safe? Commit to your answer.

Concept: Special permissions can create security risks if misused, so they must be applied carefully.

Setuid and setgid programs run with elevated privileges, so bugs or malicious code can lead to system compromise. Only trusted, necessary programs should have these bits set. The sticky bit should be used on shared directories to prevent accidental or malicious file deletion. Regular audits help maintain security.

Result

Proper use of special permissions enhances security; misuse can cause vulnerabilities.

Understanding risks helps prevent common security mistakes in system administration.

8

Expert

Unexpected Behaviors and System Internals

🤔Before reading on: do you think setuid works on scripts the same way as binaries? Commit to your answer.

Concept: Setuid does not work reliably on scripts due to kernel restrictions; understanding this avoids confusion.

Most Linux systems ignore setuid on scripts for security reasons, only applying it to binaries. This prevents exploits where scripts could be manipulated. Also, some filesystems or mount options can disable special permissions. Understanding how the kernel enforces these permissions helps troubleshoot unexpected behavior.

Result

You avoid common pitfalls and understand when special permissions apply or are ignored.

Knowing kernel-level enforcement clarifies why some permissions seem ineffective and guides correct usage.

Under the Hood

When a file with setuid or setgid is executed, the Linux kernel temporarily changes the process's user or group ID to the file owner's or group's ID. This happens at the system call level before the program runs. The sticky bit on directories is enforced by the filesystem, which checks ownership before allowing file deletion or renaming.

Why designed this way?

These permissions were designed to allow controlled privilege escalation and shared resource management without giving full root access. Early Unix systems needed ways to let users run programs like password changers securely. The sticky bit was introduced to protect shared directories from accidental or malicious file removal.

┌───────────────┐
│ Execute file  │
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Kernel checks │
│ special bits  │
├───────────────┤
│ setuid?       │─Yes─▶ Change process UID to file owner
│ setgid?       │─Yes─▶ Change process GID to file group
│ sticky bit?   │─On dir, restrict file deletion
└──────┬────────┘
       │
       ▼
┌───────────────┐
│ Run program   │
│ with modified │
│ privileges   │
└───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does setuid work on shell scripts the same as binaries? Commit to yes or no.

Common Belief: Setuid works on all executable files, including scripts.

Reality: Most Linux systems ignore setuid on scripts for security reasons; it only works on binaries.

Why it matters: Believing setuid works on scripts can lead to security holes or failed privilege escalations.

Quick: Does the sticky bit prevent all users from deleting files in a directory? Commit to yes or no.

Common Belief: Sticky bit stops everyone from deleting any files in the directory.

Reality: Sticky bit only prevents users from deleting files they do not own; owners and root can still delete their files.

Why it matters: Misunderstanding sticky bit can cause incorrect assumptions about file safety in shared directories.

Quick: Does setgid on a directory change the owner of new files? Commit to yes or no.

Common Belief: Setgid on a directory changes the owner of new files to the directory's group and user.

Reality: Setgid on a directory only changes the group ownership of new files, not the user ownership.

Why it matters: Confusing ownership can cause permission issues in collaborative environments.

Quick: Can anyone set setuid on any file they own? Commit to yes or no.

Common Belief: Any user can set setuid on their own files.

Reality: Only root or users with appropriate privileges can set setuid or setgid bits; normal users cannot set these on arbitrary files.

Why it matters: Assuming all users can set special bits leads to security risks and permission errors.

Expert Zone

1

Setuid programs must be carefully coded to avoid security vulnerabilities like buffer overflows that can be exploited to gain root access.

2

Some modern Linux distributions mount filesystems with 'nosuid' option, disabling setuid and setgid bits for security, which can confuse admins.

3

Sticky bit on directories is often combined with group permissions to create secure shared workspaces, but improper group management can still cause access issues.

When NOT to use

Avoid using setuid or setgid on scripts or untrusted binaries; instead, use capabilities or sudo for privilege management. Sticky bit is not a substitute for proper access control lists (ACLs) when fine-grained permissions are needed.

Production Patterns

In production, setuid is commonly used on programs like 'passwd' to allow password changes securely. Setgid is used on shared project directories to maintain group ownership. Sticky bit is standard on /tmp to prevent users from deleting others' temporary files.

Connections

Access Control Lists (ACLs)

Builds-on

Understanding special permissions helps grasp ACLs, which provide more detailed permission control beyond basic and special bits.

User Roles and Privileges in Databases

Similar pattern

Both Linux special permissions and database roles manage who can do what with resources, showing a common approach to security across systems.

Social Permission Systems

Analogous concept

Special permissions in Linux resemble social rules about who can access or modify shared resources, highlighting how technical systems mirror human collaboration.

Common Pitfalls

#1 Setting setuid on a script expecting it to run with elevated privileges.

Wrong approach:

chmod u+s myscript.sh
./myscript.sh

Correct approach:

Use a compiled binary with setuid or configure sudo for script execution with privileges.

Root cause:

Kernel ignores setuid on scripts for security, so the permission has no effect.

#2 Applying sticky bit on a file instead of a directory.

Wrong approach:

chmod +t myfile.txt

Correct approach:

chmod +t mydirectory/

Root cause:

Sticky bit only affects directories; setting it on files has no meaningful effect.

#3 Assuming setgid on a directory changes user ownership of new files.

Wrong approach:

chmod g+s shared_dir
# Expect new files to have directory's user ownership

Correct approach:

Understand setgid only affects group ownership; user ownership remains the creator's.

Root cause:

Misunderstanding the scope of setgid on directories.

Key Takeaways

Special permissions setuid, setgid, and sticky bit extend basic Linux permissions to control execution privileges and file deletion rights.

Setuid and setgid allow programs to run with the file owner's or group's permissions, enabling controlled privilege escalation.

Sticky bit protects files in shared directories by restricting deletion to file owners and root, preventing accidental or malicious removal.

These permissions must be used carefully to avoid security risks and are often combined with other permission systems for robust access control.

Understanding kernel enforcement and filesystem behavior is essential to correctly apply and troubleshoot special permissions.