Permissions (Part 2)
LPIC-1LINUX


TL;DR
4000 - SUID - For an executable file. Like with /usr/bin/passwd Changing password for a regular user. Binary file is executed as the user ownership, usually root - u+s
chmod u+xs /usr/bin/passwd # this would have been the command for SUID to work
2000 - SGID - For an executable file. A binary file is executed as the group ownership - g+s
chmod g+xs /usr/bin/myprogram
2000 - SGID - For a directory. Group of the directory inheritance of group permissions. Collaborative file sharing under that directory - Users must be in the same group; umask must allow files in the directory to have write permissions for the group - g+s
chmod g+wxs /opt/collab
chown root:devteam /opt/collab
usermod -aG devteam username # user needs to logout and login back
1000 - Sticky bit - For a directory. /tmp Can't delete others files under that directory - o+t
chmod o+xt /tmp # this would be the command to set the Sticky bit in the /tmp dir
----------------------------------------
1. SUID (Set User ID) (s)
When the SUID bit is set on an executable, any user who runs that file will execute it with the permissions of the file's owner (usually root), rather than their own.
Symbolic representation: rwsr-xr-x (The s replaces the x in the owner field).
Numerical value: 4000
Command: chmod u+xs /usr/bin/passwd
The Example: /usr/bin/passwd
In Linux, user passwords are stored in /etc/shadow, a file that only the root user can write to for security reasons. However, a regular user needs to be able to change their own password.
A user runs the passwd command.
Because the passwd binary has the SUID bit set and is owned by root, the command runs with root privileges.
This allows the command to temporarily "reach into" /etc/shadow and update the password.
Once the command finishes, the user returns to their normal, restricted permissions.
2. SGID (Set Group ID) (s)
SGID has two different behaviors depending on whether it is applied to a file or a directory.
On a File
Similar to SUID, the file executes with the permissions of the group that owns the file.
Symbolic: r-xr-sr-x (The s is in the group field).
Numerical: 2000
There's no need to add the write permission to the group with SGID, adding it can pose a security risk.
On a Directory (The most common use)
This is used for collaboration. When SGID is set on a directory, any new files or subdirectories created inside it will inherit the Group ID of the parent directory, rather than the primary group of the user who created the file.
The Example: Shared Project Folder
Imagine a team of developers working in a folder called /projects/alpha.
The folder is owned by the group devs.
Without SGID: If User A (group devs) creates a file, the group ownership might default to User A's private group, making it hard for User B to edit it.
With SGID: Any file User A creates will automatically be owned by the devs group, ensuring everyone in that group has the necessary access immediately.
Symbolic: For example, rwxrwsr-x, where the group has also write and execute permissions so the users can create/delete/rename files and take full advantage of SGID.
There are a couple of considerations to make the SGID work properly:
The user attempting to create a file in this collaborative directory, must be in the same group as the group owner of the directory.
If the user has a umask that doesn't allow collaboration, for example, that create files as -rw-r--r--, that would make useless the SGID, so the umask must allow other users of the same group to modify the files. The resulting permissions for the files should be -rw-rw-r-- by default. The proper way of changing this is to use ACLs, so you do not have to modify the umask that is set by default for the user.
Summary of commands:
chmod g+wxs /opt/collab
chown root:devteam /opt/collab
usermod -aG devteam username
One exam-relevant detail about usermod -aG: the user needs to log out and back in for the new group membership to take effect in their session. The kernel only reads group memberships at login time into the process credentials.
3. The "Sticky Bit" (t)
The example: /tmp directory
When using ls -ld /tmp, you’ll see rwxrwxrwt. That t at the end means that even if a user has w and x permissions on a directory, they can only delete files that they personally own. This prevents users from deleting each other's work in shared folders.
Symbolic: rwxrwxrwt (the t is in the others field).
Numerical: 1000
Command: chmod o+xt /tmp
Summary Comparison
Special Bit Numerical Symbolic Main Effect
SUID 4000 u+s File runs as the Owner.
SGID 2000 g+s File runs as the Group (or new files inherit the Group).
Sticky Bit 1000 o+t Only the owner can delete files in that directory.
Note: If you see a capital S (e.g., rwS---), it means the bit is set, but the underlying execution (x) permission is missing. For the bit to actually function, the file must also be executable (lowercase s).
Symbolic vs. Numeric
You can change permissions using u+s or 4755.
Use Symbolic (chmod g+s) when you only want to change one specific thing without touching the rest.
Use Numeric (chmod 2755) when you want to "reset" the entire permission string to a specific state.
For regular permissions, go to Part 1.
Contact
hello@unixtips.eu
© 2025. All rights reserved.