Special permissions (setuid, setgid, sticky bit) in Linux CLI - Commands & Configuration

Introduction

Sometimes, files and folders need special rules to control who can run them or change them. Special permissions like setuid, setgid, and the sticky bit help with this by giving extra powers or restrictions to users when they use these files or folders.

When you want a program to run with the permissions of its owner, not the user running it, like a password changer.

When you want files created in a shared folder to belong to the folder's group automatically.

When you want to prevent users from deleting or renaming files in a shared folder unless they own the file.

When you want to allow users to run a script with the owner's permissions safely.

When managing shared directories like /tmp where many users write files but should not delete others' files.

Commands

Check the current permissions of the passwd program to see if setuid is set.

Terminal

ls -l /usr/bin/passwd

Expected Output

-rwsr-xr-x 1 root root 54256 Apr 12 2024 /usr/bin/passwd

→

-l - Show detailed file permissions and ownership

Set the setuid bit on the passwd program so it runs with the owner's permissions (root).

Terminal

chmod u+s /usr/bin/passwd

Expected Output

No output (command runs silently)

→

u+s - Add setuid permission to the file

Set the setgid bit on a shared folder so new files inherit the folder's group.

Terminal

chmod g+s /shared_folder

Expected Output

No output (command runs silently)

→

g+s - Add setgid permission to the directory

Set the sticky bit on a shared folder to prevent users from deleting files they do not own.

Terminal

chmod +t /shared_folder

Expected Output

No output (command runs silently)

→

+t - Add sticky bit permission to the directory

Verify the special permissions on the shared folder by listing its details.

Terminal

ls -ld /shared_folder

Expected Output

drwxrwsr-t 5 user group 4096 Apr 27 12:00 /shared_folder

→

-ld - List directory details without showing contents

Key Concept

If you remember nothing else from this pattern, remember: setuid runs a file as its owner, setgid makes new files inherit group ownership, and the sticky bit protects shared files from being deleted by others.

Common Mistakes

Setting setuid on a directory instead of a file

Setuid only works on executable files, not directories, so it has no effect on directories.

Use setgid on directories to control group inheritance, and setuid only on executable files.

Forgetting to check permissions after setting special bits

You might think the permission changed, but it did not apply correctly or was overwritten.

Always verify with ls -l or ls -ld to confirm the special permissions are set.

Setting sticky bit on files instead of directories

Sticky bit on files is ignored on modern systems; it only works on directories to restrict deletion.

Apply sticky bit only on directories where you want to protect files from deletion by others.

Summary

Use chmod u+s to set the setuid bit so a program runs with its owner's permissions.

Use chmod g+s on directories to make new files inherit the directory's group.

Use chmod +t on shared directories to prevent users from deleting files they do not own.

Verify special permissions with ls -l for files and ls -ld for directories.

Practice

1. What does the setuid permission do on an executable file?

easy

A. Runs the program with the file owner's permissions

B. Allows anyone to delete the file

C. Makes new files inherit the folder's group

D. Prevents the file from being executed

Solution

1. Step 1: Understand setuid purpose

   The setuid permission allows a program to run with the permissions of the file owner, not the user running it.

2. Step 2: Compare options with setuid behavior

   Only Runs the program with the file owner's permissions correctly describes this behavior; others describe different permissions or incorrect effects.

3. Final Answer:

   Runs the program with the file owner's permissions -> Option A

4. Quick Check:

   setuid = runs as owner [OK]

Hint: Setuid means run as file owner, not current user [OK]

Common Mistakes:

• Confusing setuid with sticky bit
• Thinking setuid changes file deletion rights
• Mixing setuid with setgid effects

2. Which command correctly sets the setgid bit on a directory named shared?

easy

A. chmod g+s shared

B. chmod +s shared

C. chmod u+s shared

D. chmod o+s shared

Solution

1. Step 1: Identify correct chmod syntax for setgid

   The setgid bit is set using g+s with chmod on directories.

2. Step 2: Verify options

   chmod g+s shared uses chmod g+s shared, which is correct. Other options use incorrect flags or users.

3. Final Answer:

   chmod g+s shared -> Option A

4. Quick Check:

   Setgid = chmod g+s [OK]

Hint: Setgid uses 'g+s' with chmod on directories [OK]

Common Mistakes:

• Using '+s' without user class
• Confusing setuid (u+s) with setgid
• Trying to set setgid on files with wrong syntax

3. Given a directory /tmp/shared with permissions drwxrwxrwt, what does the t at the end signify?

medium

A. Setuid bit is set

B. Sticky bit is set

C. Setgid bit is set

D. No special permissions set

Solution

1. Step 1: Interpret permission string ending with 't'

   The 't' at the end of directory permissions indicates the sticky bit is set.

2. Step 2: Match 't' with sticky bit meaning

   The sticky bit prevents users from deleting files they don't own in that directory.

3. Final Answer:

   Sticky bit is set -> Option B

4. Quick Check:

   't' at end = sticky bit [OK]

Hint: 't' at end of permissions means sticky bit set [OK]

Common Mistakes:

• Confusing 't' with setuid or setgid
• Thinking 't' means no special permission
• Misreading permissions string

4. You set the setuid bit on a script using chmod u+s script.sh, but it doesn't run with owner permissions. What is the likely problem?

medium

A. You need to set the sticky bit instead

B. The file owner must be root for setuid to work

C. The script is a shell script and setuid does not work on scripts

D. You forgot to set execute permission

Solution

1. Step 1: Understand setuid behavior on scripts

   Most Linux systems ignore setuid on shell scripts for security reasons.

2. Step 2: Evaluate other options

   Sticky bit is unrelated, owner need not be root, and execute permission is usually set if script runs.

3. Final Answer:

   The script is a shell script and setuid does not work on scripts -> Option C

4. Quick Check:

   Setuid ignored on scripts [OK]

Hint: Setuid rarely works on scripts, only on binaries [OK]

Common Mistakes:

• Assuming setuid works on all files
• Confusing sticky bit with setuid
• Not checking execute permission

5. You want to create a shared directory /data/shared where all files created inside inherit the directory's group and users cannot delete others' files. Which commands set this up correctly?

hard

A. chmod 2777 /data/shared && chmod g+s /data/shared

B. chmod 777 /data/shared && chmod g+s /data/shared

C. chmod 2777 /data/shared

D. chmod 2777 /data/shared && chmod +t /data/shared

Solution

1. Step 1: Set setgid and sticky bit on directory

   Setgid (2) makes new files inherit group; sticky bit (1) prevents deleting others' files.

2. Step 2: Analyze commands

   chmod 2777 /data/shared && chmod +t /data/shared sets permissions to 2777 (setgid + rwxrwxrwx) and adds sticky bit with chmod +t. This correctly applies both.

3. Final Answer:

   chmod 2777 /data/shared && chmod +t /data/shared -> Option D

4. Quick Check:

   Setgid + sticky bit = chmod 2777 + t [OK]

Hint: Setgid=2xxx, sticky=1xxx; combine for shared dir [OK]

Common Mistakes:

• Using sticky bit without setgid
• Confusing octal codes for permissions
• Setting wrong permission order