Understanding Linux Special Permissions: SetUID, SetGID, and the Sticky Bit
Introduction
Beyond the basic Read (r), Write (w), and Execute (x) permissions, Linux offers special permissions that grant enhanced control over how files and directories behave. These are the SetUID (SUID), SetGID (SGID), and Sticky Bit, and understanding them is crucial for advanced security and system management. They are often used by system programs to perform privileged operations or to manage shared directories.
Viewing Special Permissions
Special permissions are visible in the `ls -l` output, appearing in place of the `x` (execute) permission for the owner, group, or others, or as a capital letter if the execute bit is not also set.
Example output for special permissions:
[Code]-rwsr-xr-x 1 root root 45K Apr 20 2024 /usr/bin/passwd
drwxrwsr-x 2 user group 4.0K May 15 2024 /var/mail
drwxrwxrwt 7 root root 4.0K Jun 10 2024 /tmp[/Code]
Let's break down how they appear:
- s (lowercase): The special permission is set AND the execute permission (`x`) for that category (user or group) is also set.
- S (uppercase): The special permission is set, but the execute permission (`x`) for that category (user or group) is NOT set.
- t (lowercase): The sticky bit is set AND the execute permission (`x`) for others is also set.
- T (uppercase): The sticky bit is set, but the execute permission (`x`) for others is NOT set.
SetUID (SUID)
Purpose:
The SetUID permission is primarily applied to executable files. When a SetUID-enabled executable is run, it executes with the permissions of the file's owner, rather than the permissions of the user who is running it.
How it appears in `ls -l`:
The `x` for the user (owner) permissions slot changes to an `s`. If the user execute bit isn't set, it will be `S` (uppercase).
Example: `-rwsr-xr-x` (SetUID is active, and owner has execute permission)
Use Case Example:
A common example is the `/usr/bin/passwd` command. When you change your password, you are modifying a system file (`/etc/shadow`) that only the `root` user has write access to. However, because the `passwd` executable has the SetUID bit set, it temporarily runs with `root`'s privileges, allowing your password change to be written to the secure file, even though you are just a regular user.
Setting SetUID:
- Symbolic Mode: `u+s`
chmod u+s /path/to/executable
- Numeric (Octal) Mode: Add `4` to the usual numeric permissions.
chmod 4755 /path/to/executable
(Here, `4` for SetUID, `7` for owner rwx, `5` for group rx, `5` for others rx. Total `4755`).
Security Concern:
SetUID programs are a potential security risk if not handled carefully, as they can be exploited to gain unauthorized root access if poorly written or configured. Always be cautious when setting SetUID permissions.
SetGID (SGID)
Purpose (on Files):
Similar to SetUID, when SetGID is applied to an executable file, the program runs with the permissions of the file's group, rather than the primary group of the user executing it.
Purpose (on Directories - More Common Use):
This is where SetGID is most commonly used. When SetGID is set on a directory, any new files or subdirectories created within that directory automatically inherit the group ownership of the parent directory, instead of the primary group of the user who created them. This is extremely useful for shared directories where multiple users need to collaborate on files.
How it appears in `ls -l`:
The `x` for the group permissions slot changes to an `s`. If the group execute bit isn't set, it will be `S` (uppercase).
Example: `drwxrwsr-x` (SetGID is active, and group has execute permission)
Use Case Example:
Imagine a project directory `/projects/team_alpha` owned by `root:team_alpha`. If SetGID is set on this directory, any file created by `user1` (whose primary group is `users`) within `/projects/team_alpha` will automatically be owned by `user1:team_alpha`, ensuring all team members can access and modify it based on the `team_alpha` group permissions.
Setting SetGID:
- Symbolic Mode: `g+s`
chmod g+s /path/to/file_or_directory
- Numeric (Octal) Mode: Add `2` to the usual numeric permissions.
chmod 2775 /path/to/directory
(Here, `2` for SetGID, `7` for owner rwx, `7` for group rwx, `5` for others rx. Total `2775`).
The Sticky Bit
Purpose:
The Sticky Bit is primarily applied to directories. When set on a directory, it restricts file deletion. Users can only delete or rename files within that directory if they are:
- The owner of the file.
- The owner of the directory.
- The root user.
This prevents users from deleting or renaming files created by others in a shared, writable directory.
How it appears in `ls -l`:
The `x` for the others permissions slot changes to a `t`. If the others execute bit isn't set, it will be `T` (uppercase).
Example: `drwxrwxrwt` (Sticky Bit is active, and others have execute permission)
Use Case Example:
The most famous example is the `/tmp` directory. This is a globally writable directory where all users can create temporary files. Without the Sticky Bit, any user could delete any other user's files in `/tmp`. With the Sticky Bit, you can only delete your own files in `/tmp`, making it safe for shared use.
Setting Sticky Bit:
- Symbolic Mode: `o+t`
chmod o+t /path/to/directory
- Numeric (Octal) Mode: Add `1` to the usual numeric permissions.
chmod 1777 /path/to/directory
(Here, `1` for Sticky Bit, `7` for owner rwx, `7` for group rwx, `7` for others rwx. Total `1777`).
Summary of Numeric Values for Special Permissions
When combining special permissions with regular `rwx` permissions, you add an extra digit at the beginning of the three-digit octal number:
- 4 = SetUID
- 2 = SetGID
- 1 = Sticky Bit
Example: `chmod 4755 filename` (SetUID + rwxr-xr-x)
Example: `chmod 2770 directory` (SetGID + rwxrwx- --)
Example: `chmod 1777 /tmp` (Sticky Bit + rwxrwxrwx)
Conclusion
SetUID, SetGID, and the Sticky Bit are powerful tools for managing file and directory behavior in Linux, particularly in multi-user environments. While they offer significant functionality, especially for system commands and shared workspaces, it's crucial to understand their implications and apply them with caution, especially SetUID, due to potential security risks if misused.