Special permissions (setuid, setgid, sticky bit) in Linux CLI - Time & Space Complexity
When working with special permissions like setuid, setgid, and the sticky bit, it's important to understand how the system checks these permissions during file access.
We want to know how the time it takes to verify these permissions changes as the number of files or users grows.
Analyze the time complexity of checking special permissions on files in a directory.
for file in /some/directory/*; do
ls -l "$file" | grep '[sStT]'
done
This script lists files and filters those with special permission bits set.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Looping over each file in the directory and checking its permissions.
- How many times: Once per file in the directory.
As the number of files increases, the script checks each file one by one.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 permission checks |
| 100 | 100 permission checks |
| 1000 | 1000 permission checks |
Pattern observation: The number of permission checks grows directly with the number of files.
Time Complexity: O(n)
This means the time to check special permissions grows linearly with the number of files.
[X] Wrong: "Checking special permissions happens instantly no matter how many files there are."
[OK] Correct: Each file's permissions must be checked separately, so more files mean more checks and more time.
Understanding how permission checks scale helps you reason about system performance and security in real environments.
"What if we cached permission checks for files? How would that affect the time complexity?"
Practice
setuid permission do on an executable file?Solution
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.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.Final Answer:
Runs the program with the file owner's permissions -> Option AQuick Check:
setuid = runs as owner [OK]
- Confusing setuid with sticky bit
- Thinking setuid changes file deletion rights
- Mixing setuid with setgid effects
shared?Solution
Step 1: Identify correct chmod syntax for setgid
The setgid bit is set usingg+swith chmod on directories.Step 2: Verify options
chmod g+s shared useschmod g+s shared, which is correct. Other options use incorrect flags or users.Final Answer:
chmod g+s shared -> Option AQuick Check:
Setgid = chmod g+s [OK]
- Using '+s' without user class
- Confusing setuid (u+s) with setgid
- Trying to set setgid on files with wrong syntax
/tmp/shared with permissions drwxrwxrwt, what does the t at the end signify?Solution
Step 1: Interpret permission string ending with 't'
The 't' at the end of directory permissions indicates the sticky bit is set.Step 2: Match 't' with sticky bit meaning
The sticky bit prevents users from deleting files they don't own in that directory.Final Answer:
Sticky bit is set -> Option BQuick Check:
't' at end = sticky bit [OK]
- Confusing 't' with setuid or setgid
- Thinking 't' means no special permission
- Misreading permissions string
chmod u+s script.sh, but it doesn't run with owner permissions. What is the likely problem?Solution
Step 1: Understand setuid behavior on scripts
Most Linux systems ignore setuid on shell scripts for security reasons.Step 2: Evaluate other options
Sticky bit is unrelated, owner need not be root, and execute permission is usually set if script runs.Final Answer:
The script is a shell script and setuid does not work on scripts -> Option CQuick Check:
Setuid ignored on scripts [OK]
- Assuming setuid works on all files
- Confusing sticky bit with setuid
- Not checking execute permission
/data/shared where all files created inside inherit the directory's group and users cannot delete others' files. Which commands set this up correctly?Solution
Step 1: Set setgid and sticky bit on directory
Setgid (2) makes new files inherit group; sticky bit (1) prevents deleting others' files.Step 2: Analyze commands
chmod 2777 /data/shared && chmod +t /data/shared sets permissions to 2777 (setgid + rwxrwxrwx) and adds sticky bit withchmod +t. This correctly applies both.Final Answer:
chmod 2777 /data/shared && chmod +t /data/shared -> Option DQuick Check:
Setgid + sticky bit = chmod 2777 + t [OK]
- Using sticky bit without setgid
- Confusing octal codes for permissions
- Setting wrong permission order
Ready to prove it?
Pass the test and this pattern moves unknown
