> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Special Permissions

> Explains SUID, SGID, and the sticky bit, their effects, use cases, configuration commands, and best practices for shared Linux directories

Standard Linux file permissions cover read, write, and execute. In addition, three special permission bits alter how the system applies privileges, how group ownership is inherited, or who can delete files in shared directories. These special bits do not directly grant or deny access; instead, they change behavior and enforce collaboration rules.

This guide explains:

* what SUID, SGID, and the sticky bit do,
* practical use cases (especially for shared directories),
* commands to configure and verify them,
* a real-world SUID example (the `passwd` command).

<Frame>
  <img src="https://mintcdn.com/kodekloud-c4ac6d9a/9E2T0ocsNwD7Od8i/images/Prep-Course-Red-Hat-Certified-System-Administrator-RHCSA/Linux-Permissions/Special-Permissions/special-permissions-shared-workspace-icons.jpg?fit=max&auto=format&n=9E2T0ocsNwD7Od8i&q=85&s=40d2809df811d01b5d2c9eaf54df2b4b" alt="A dark-themed slide titled &#x22;Special Permissions&#x22; with the subtitle &#x22;Special rules in a shared workspace.&#x22; Three circular icons across the center illustrate: temporarily elevate user authority; enforce shared team ownership; and protect shared areas for safe collaboration." width="1920" height="1080" data-path="images/Prep-Course-Red-Hat-Certified-System-Administrator-RHCSA/Linux-Permissions/Special-Permissions/special-permissions-shared-workspace-icons.jpg" />
</Frame>

<Callout icon="lightbulb" color="#1CB2FE">
  Special permissions modify behavior rather than typical access. Use them intentionally—especially SUID—because they affect security boundaries.
</Callout>

## At a glance: What each special bit does

| Special Bit | Effect on files | Effect on directories | Typical use case |
| - | - | - | - |
| SUID (set-user-ID) | When set on an executable, the process runs with the file owner's UID instead of the invoking user's UID. | No effect on directories. | Allow specific programs to perform actions as the file owner (e.g., `passwd`). |
| SGID (set-group-ID) | When set on an executable, the process runs with the file's GID. | New files and subdirectories inherit the parent directory's group ownership. | Maintain consistent group ownership for files in a shared workspace. |
| Sticky bit | Deprecated on regular files; no meaningful effect on modern filesystems. | Restricts deletion inside the directory: only file owner, directory owner, or root can remove files. | Secure shared directories (e.g., `/tmp`, team shares) to prevent accidental or unauthorized deletions. |

## Permission bit notation quick reference

* The `s` character appears in place of an `x` when SUID or SGID is set and the execute bit is present (e.g., `rws`).
* An uppercase `S` or `T` indicates the special bit is set but the corresponding execute bit is not set.
* Use `chmod` with numeric or symbolic notation:
  * Numeric: `chmod 4755 file` sets SUID (`4` = SUID).
  * Numeric: `chmod 2750 dir` sets SGID (`2` = SGID).
  * Numeric: `chmod 1777 /tmp` sets the sticky bit (`1` = sticky).

## Demo: Shared directory with SGID + sticky bit

Scenario assumptions:

* Two users: `dev1` and `dev2`.
* Both users are members of group `devteam`.
* We create a shared directory `/shared`, make root the owner, and configure group-controlled collaboration.

1. Create the shared directory, set ownership and SGID with full owner/group permissions, no permissions for others:

```bash theme={null}
# as root
mkdir /shared
chown root:devteam /shared
chmod 2770 /shared
```

2. Verify directory permissions and SGID bit:

```bash theme={null}
ls -ld /shared
```

Expected output (the `s` in the group permission slot indicates SGID):

```text theme={null}
drwxrws---. 2 root devteam 4096 Jun 10 12:00 /shared
```

3. Test SGID inheritance:

* Switch to `dev1`, create a file in `/shared`, and inspect ownership.

```bash theme={null}
# as root
su dev1

# as dev1
cd /shared
touch file1
ls -l file1
```

Expected output (note the file group is `devteam` due to SGID on the directory):

```text theme={null}
-rw-r--r-- 1 dev1 devteam 0 Jun 10 12:01 file1
```

SGID ensures new files inherit the shared directory's group, helping teams manage group access consistently.

4. Enable the sticky bit so only file owners (or the directory owner/root) can delete files:

```bash theme={null}
# back to root
exit    # return to root if needed
chmod +t /shared
ls -ld /shared
```

Expected output (notice the uppercase `T` because "others" have no execute bit; sticky bit is present):

```text theme={null}
drwxrws--T. 2 root devteam 4096 Jun 10 12:00 /shared
```

5. Test deletion restriction with the sticky bit:

* Switch to `dev2` and try to remove `file1` (owned by `dev1`).

```bash theme={null}
su dev2
cd /shared
rm file1
```

Example session showing the deletion is blocked:

```text theme={null}
dev2@control:/# cd /shared
dev2@control:/shared$ rm file1
rm: remove write-protected regular empty file 'file1'? y
rm: cannot remove 'file1': Operation not permitted
dev2@control:/shared$
```

Even though `dev2` is in `devteam` and group permissions might otherwise allow deletion, the sticky bit prevents `dev2` from removing a file owned by `dev1`. Only `dev1`, the directory owner (`root`), or `root` can remove it.

<Callout icon="warning" color="#FF6B6B">
  Do not broadly apply SUID to arbitrary executables—doing so can introduce serious security risks. Use SUID only for carefully audited programs that require it.
</Callout>

## Real-world SUID example: /usr/bin/passwd

A classic SUID binary is `/usr/bin/passwd`. Regular users must be able to update their password, which requires writing to `/etc/shadow`—a file owned by `root`. Setting SUID on the `passwd` program allows the program to run with root privileges while the user still only executes the `passwd` binary.

Check the `passwd` binary:

```bash theme={null}
ls -l /usr/bin/passwd
```

Example output showing the SUID bit in the owner permission (`s` in place of `x`):

```text theme={null}
-rwsr-xr-x. 1 root root 91416 May 26 2025 /usr/bin/passwd
```

Because `passwd` is setuid to root, it can update `/etc/shadow` on behalf of a user without granting the user full root privileges.

## Summary and best practices

* Use SGID on shared directories to ensure new files inherit the group's ownership and simplify permission management.
* Use the sticky bit on shared directories (like `/tmp` or team shares) to prevent users from deleting other users' files.
* Apply SUID sparingly and only to well-audited, trusted binaries that require elevated privileges for a limited, specific task.
* Always verify permission bits with `ls -l` and test behavior with representative users.

Further reading and references:

* [Linux File Permissions](https://www.kernel.org/doc/html/latest/filesystems/permissions.html)
* [chmod manpage](https://man7.org/linux/man-pages/man1/chmod.1.html)
* [Understanding setuid, setgid, and sticky bits](https://www.redhat.com/sysadmin/setuid-setgid-sticky)

<CardGroup>
  <Card title="Watch Video" icon="video" cta="Learn more" href="https://learn.kodekloud.com/user/courses/red-hat-certified-system-administrator-rhcsa/module/3c103226-2d1c-4dd2-ac12-db543617e7c2/lesson/cf82b021-7d8c-4bbe-b519-0e50b5612522" />
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.