# Sticky bit

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/sticky-bit

## Quick definition

The sticky bit is a special setting you can apply to a directory (or file) on a Linux system. When set on a directory, it prevents users from deleting or renaming files that they do not own, even if they have write permission on the directory. This is commonly used on shared directories like /tmp to keep users from messing with each other's files. You will not see it often on regular files, but on directories it is a vital security feature.

## Simple meaning

Imagine a shared locker room where everyone in a community can put their own gym bag on any shelf. The locker room is a shared space, and normally anyone with a key could grab any bag, even if it belongs to someone else. But now the community manager puts a special sticky note on the door that says: "You can only take your own bag." This sticky note changes the rule: even though the room is open to everyone, each person is only allowed to remove the bag they themselves placed there. That sticky note is like the sticky bit in a computer system.

In the world of Linux and Unix systems, folders (called directories) can have different permissions. The most common permissions are read, write, and execute. If a directory has write permission for everyone, any user could delete any file inside it, even files created by someone else. That would be chaos on a shared system, like a public computer lab or a web server where many people store temporary files.

The sticky bit solves this problem. When a directory has the sticky bit set (often shown as a 't' at the end of the permission string, like drwxrwxrwt), the system enforces an extra rule: only the owner of a file, the owner of the directory, or the root administrator can delete or rename that file. All other users, even if they have write access to the folder, are blocked from touching files that do not belong to them.

This is a simple but powerful idea. It does not change who can read or write the files themselves. It only affects the ability to delete or rename items. The sticky bit is a way to share a directory without letting anyone abuse the shared space. It is a cornerstone of secure multi-user environments, used in places like /tmp, /var/tmp, and shared project folders. Without it, any user could accidentally or maliciously destroy another user's work in a shared folder.

## Technical definition

The sticky bit is a special file permission flag defined in the POSIX standard for Unix-like operating systems. It is represented numerically by the octal value 1000 when using commands like chmod. In symbolic mode, it is represented by the letter 't' in the execute position of the 'others' permission triplet when viewing a directory listing with ls -l. For example, a directory with permissions drwxrwxrwt indicates that the sticky bit is set. If the execute permission for others is not set, the sticky bit appears as a capital 'T' instead (drwxrwxrwT).

Historically, on older Unix systems, the sticky bit had a different function for executable files. It would cause the program's text segment (the code) to remain in swap memory after the process exited, making subsequent executions faster. This is why it was called the "sticky" bit, the program would "stick" in memory. Modern Linux and most contemporary Unix systems ignore this behavior for regular files because memory management has become far more efficient, and the swap-based caching is no longer beneficial. Today, the sticky bit's primary purpose is on directories.

When the sticky bit is applied to a directory, it modifies the deletion semantics. Normally, a user needs write permission on a directory to delete or rename any file inside it, regardless of file ownership. This is because the directory itself is just a list of file names and inode references. Removing a file means editing that list. With the sticky bit set, the kernel's Virtual File System (VFS) layer adds an extra check: before allowing an unlink() or rename() system call on an entry within that directory, the kernel verifies that the calling process has the effective user ID matching either the owner of the directory, the owner of the file, or the superuser (root).

From a technical perspective, the sticky bit is stored in the file's inode metadata, specifically in the mode field. When you run ls -l, the permission string shows the sticky bit in the last character position. The underlying permissions are stored as a 16-bit integer where the top 4 bits represent setuid, setgid, and sticky bits. The octal representation is: setuid=4000, setgid=2000, sticky=1000. So to set the sticky bit while preserving other permissions, you would use chmod 1755 directoryname or chmod +t directoryname.

In Linux kernel source code (fs/namei.c), the operation of checking the sticky bit is implemented in the may_delete() function. This function checks if the directory has the S_ISVTX flag (the sticky bit constant). If it does, it verifies that the user either owns the directory, owns the file being deleted, or has the CAP_FOWNER capability (which root has). This check happens before any filesystem-specific unlink operation begins. It applies to both regular files and subdirectories within the sticky-bit directory.

The sticky bit works across all common Linux filesystems including ext4, XFS, Btrfs, and tmpfs. It is also supported on macOS (though not on the default APFS filesystem for all directory types) and other Unix variants. Network filesystems like NFS may also respect the sticky bit if the server and client implementations conform to the POSIX standard. It is a fundamental access control mechanism for shared writable directories in multi-user environments, and IT professionals must understand how it interacts with standard Unix file permissions.

## Real-life example

Think of a public library where there is a community corkboard. Anyone can pin a notice to the board, and anyone can read the notices. Normally, if you have a pin, you could also remove any notice you want, even if it was posted by someone else. Now imagine the library puts a special rule in place: "Each person may only remove their own notices." They do this by requiring that each notice has the person's name on it, and the library staff will only allow you to take down a notice that has your name on it. This is exactly how the sticky bit works on a computer.

In this analogy, the corkboard is the directory. The pins represent write permission, everyone can pin up a new file. The notices are the files themselves. The library rule is the sticky bit. Without the sticky bit, any user (any library visitor) could pull down any notice. With the sticky bit, only the person who put up the notice (the file owner) can remove it.

Now imagine a shared project room in an office. There is a whiteboard and a marker. Anyone can write on the board, but the office policy says you cannot erase someone else's writing unless they give you permission. The whiteboard is the shared directory, the marker is write access, and the policy is the sticky bit. This prevents one team member from accidentally wiping out another's work when cleaning the board.

In the digital world, the most common place you will see this is the /tmp directory on any Linux server. Hundreds of users and system processes create temporary files in /tmp. Without the sticky bit, one user could delete another user's temporary files, causing crashes or data loss. The sticky bit ensures that the /tmp directory remains a safe shared space. It is a simple, elegant solution to a problem that would otherwise require complex per-user directories or manual supervision. The same principle applies to shared project directories on a development server, where multiple developers might need to create build artifacts or logs in a common location.

## Why it matters

The sticky bit matters because it is one of the fundamental security controls that enables safe multi-user computing on Unix-like systems. In any IT environment where multiple users share a server, whether it is a web server, a database server, a development machine, or a cloud instance, there will be shared directories. Without the sticky bit, those directories would be a vector for accidental or malicious file destruction. A junior developer could accidentally delete a production log file. A malicious user could delete critical temporary files used by a running service, causing a denial of service. The sticky bit prevents these scenarios with a single permission flag.

For system administrators, the sticky bit is a standard configuration element. When you create a shared directory for a team, you almost always set the sticky bit. When you check the permissions of /tmp, /var/tmp, or any user-upload directory in a web application, you expect to see the sticky bit. If you find it missing, that is a security finding that needs immediate remediation. Many security scanning tools (like CIS benchmarks, Lynis, or OpenSCAP) check for the sticky bit on world-writable directories and flag it as a vulnerability if it is missing.

From a compliance perspective, standards like PCI DSS, HIPAA, and SOC 2 require that systems enforce proper access controls. While they do not explicitly name the sticky bit, the underlying principle, that users should not be able to delete other users' files in shared spaces, is a core requirement. Auditors will look for evidence that shared directories are protected, and the sticky bit is the simplest way to demonstrate that.

In development workflows, the sticky bit is also important. Build servers, Continuous Integration (CI) runners, and shared artifact repositories often use directories with the sticky bit to prevent build processes from interfering with each other. When you run Docker containers that mount host directories, the sticky bit can prevent containerized processes from deleting files created by other containers. Understanding the sticky bit helps a professional troubleshoot permission issues, write secure scripts, and design robust multi-tenant systems. It is a small detail with big consequences, and it appears regularly in system administration job interviews and certification exams.

## Why it matters in exams

The sticky bit is a recurring topic in general IT certifications because it tests a candidate's understanding of Unix/Linux file permissions beyond the basic read-write-execute triad. For CompTIA Linux+ (XK0-005), the sticky bit is explicitly listed in the exam objectives under "File permissions and ownership." Questions may ask you to identify the permission string that includes the sticky bit, to use chmod to set it, or to explain its effect on a directory. You might see a scenario where a user cannot delete a file in /tmp even though they have write permission, and you need to explain why; that is the sticky bit in action.

For the LPIC-1 certification (101-500), the sticky bit is part of Objective 104.5 "Manage file permissions and ownership." Candidates must know how to set the sticky bit using both symbolic (chmod +t) and octal (1000) methods. They must understand the difference between the sticky bit on a file (historical) versus a directory (modern use). The exam will test whether you know that the sticky bit prevents deletion of other users' files in a shared directory, and whether you can identify it in an ls -l output.

In the Red Hat Certified System Administrator (RHCSA) exam, the sticky bit appears in system administration tasks. You might be asked to create a shared directory for a group, set appropriate permissions, and apply the sticky bit. The exam could present a problem where a user reports being unable to delete a file in a shared directory, and you must diagnose whether the sticky bit is the cause. The RHCSA expects you to configure permissions precisely, so knowing how to combine setgid and sticky bit on a directory is a practical skill.

For general IT certifications like CompTIA A+ (220-1102), the sticky bit appears more lightly but still matters. You may see a question about Linux permissions where the answer is the sticky bit. CompTIA Security+ (SY0-601) might touch on the concept as part of access control mechanisms. Even Windows certifications like MCSA or modern Microsoft role-based exams may include questions about shared folder permissions, and while Windows uses different mechanisms (like ACLs), the concept of a "sticky"-like behavior in shared folders is analogous.

In the exam questions, the sticky bit is often blended with other concepts like setuid, setgid, umask, and ACLs. You might be asked which permission prevents a non-owner from deleting a file in a world-writable directory. You might need to calculate the correct octal mode to set rwx for owner and group, read-only for others, plus the sticky bit (3775? Actually 1775 decimal? No, careful: 1775 octal works: 1 for sticky, 7 for owner, 7 for group, 5 for others). The correct answer is 1775. These calculation questions test your attention to detail. Another common question type shows an ls -la output with drwxrwxrwt and asks what the 't' means. Understanding these exam patterns is key to scoring well.

## How it appears in exam questions

Exam questions about the sticky bit typically fall into three categories: permission string interpretation, command usage, and scenario-based troubleshooting. In permission string interpretation, you will be given an ls -l output like:

```
drwxrwxrwt 2 root root 4096 Mar 10 12:00 shared_folder
```

You will be asked what the 't' at the end means or what effect it has. The answer options might include "file is executable," "directory is world-writable," "only owners can delete their files," or "the file is a symbolic link." The correct answer is the one about deletion restriction.

In command usage questions, you might be asked: "Which command sets the sticky bit on the directory /data/shared?" The options could be chmod 1777 /data/shared, chmod 777 /data/shared, chmod +s /data/shared, or chmod u+t /data/shared. The correct ones are chmod 1777 /data/shared (octal) and chmod +t /data/shared (symbolic). Note that chmod u+t is wrong because 'u' refers to the user/owner, not the user bit of the sticky bit, the sticky bit is set with 'o+t' or just '+t'. Many candidates confuse this.

Scenario-based questions are the most challenging. For example: "A developer named Alice creates a file in /tmp. Bob, another user, tries to delete Alice's file using rm but gets 'Operation not permitted.' Both users have write permission on /tmp. What is the most likely reason?" The answer is the sticky bit. Another scenario: "You create a shared directory /project for your team. You set permissions to 777. Users report that they can accidentally delete each other's files. Which permission should you set?" The answer: the sticky bit.

Some questions combine permissions with umask. You might need to predict the resulting permission string when a file is created in a sticky-bit directory with a specific umask. Others test whether you know that the sticky bit on a regular file is generally ignored on modern Linux systems. A trick question might claim that setting the sticky bit on a file speeds up execution. That is a historical fact but is not true on modern systems, so you must answer correctly based on current behavior.

Troubleshooting questions may involve a user who cannot delete a file but can create files. You must check the directory permissions, see the sticky bit, and explain that the user is not the owner of the file. Another variant: a system administrator accidentally removes the sticky bit from /tmp, and users start reporting missing files. The question asks for the cause and the fix (chmod +t /tmp). These questions test your ability to connect symptoms to the underlying permission mechanism.

## Example scenario

You are a system administrator for a university's computer lab. The lab has a shared Linux server where students can store temporary files during their programming assignments. The server has a directory called /shared_work that is world-writable so anyone can save their files. However, students are complaining that other students are deleting their source code files before they can submit them.

You investigate and find that /shared_work has permissions drwxrwxrwx. That means everyone can read, write, and execute in this directory. Because write permission on a directory allows any user to delete any file inside it, a student can delete another student's file. This is a security and fairness problem.

To fix it, you set the sticky bit on /shared_work. You run: chmod +t /shared_work. Now the permissions become drwxrwxrwt. The 't' at the end indicates that the sticky bit is active. From now on, if a student named Maria creates a file called assignment1.c in /shared_work, and another student named John tries to delete it with rm /shared_work/assignment1.c, the system will deny the operation. John will see an error: "Operation not permitted." But Maria can still delete her own file, and the root user can delete any file. John can still create new files, read Maria's file (if read permissions allow), and write to his own files.

Later, a teaching assistant needs to clean up all files older than 30 days. As root, they can delete any file because root bypasses the sticky bit restriction. So the sticky bit does not prevent authorized administration, it only prevents regular users from interfering with each other.

This scenario mirrors real-world /tmp usage. On a large server with hundreds of active users, /tmp is always set with the sticky bit. Without it, the system would be unstable and insecure. The sticky bit is a simple but essential tool in any system administrator's toolkit, and understanding it helps you solve problems like this quickly.

## Common mistakes

- **Mistake:** Thinking the sticky bit prevents reading or writing files in a directory.
  - Why it is wrong: The sticky bit only affects deletion and renaming of files. It does not restrict reading, writing, or executing the files themselves. Those actions are controlled by the regular rwx permissions on the files and directories.
  - Fix: Remember: sticky bit = deletion protection only. Regular permissions still control read, write, and execute access.
- **Mistake:** Using 'chmod u+t' instead of 'chmod +t' to set the sticky bit.
  - Why it is wrong: The 'u' in chmod refers to the user (owner) class. The sticky bit is a special bit, not a user permission. The correct symbolic mode is 'chmod +t' or 'chmod o+t'. Using 'u+t' may not produce an error but will not set the sticky bit as intended on most systems.
  - Fix: Use 'chmod +t directory' or 'chmod 1xxx directory' (where xxx are the standard permission digits). Verify with 'ls -ld directory' to see the 't' at the end.
- **Mistake:** Believing the sticky bit works on files the same way as on directories in modern Linux.
  - Why it is wrong: Historically, the sticky bit on executable files caused the program to stay in swap memory. Modern Linux kernels ignore this behavior for files. On files, the sticky bit has no practical effect. The only meaningful use today is on directories.
  - Fix: Focus on the directory use of the sticky bit for exams and real-world administration. Do not rely on file sticky bit behavior.
- **Mistake:** Confusing the sticky bit with the setuid or setgid bits.
  - Why it is wrong: Setuid and setgid affect the effective user or group ID when a program runs, granting temporary elevated privileges. The sticky bit only restricts deletion in directories. They are all special permissions but have entirely different purposes.
  - Fix: Use a mental shortcut: setuid = run as owner, setgid = run as group, sticky = protect from deletion. The letters 's' and 't' in permission strings indicate which bit is set.
- **Mistake:** Thinking that a capital 'T' in permissions means the sticky bit is set strongly or is more secure.
  - Why it is wrong: A capital 'T' appears when the sticky bit is set but the execute permission for others is not set. It does not indicate a stronger version. It simply shows that the sticky bit is active without execute permission. It is functionally the same, but it looks different in ls output.
  - Fix: When you see 'T', know that the sticky bit is present but the execute bit is missing. The behavior is identical. To avoid confusion, ensure the execute bit is set on directories that need to be browsed.

## Exam trap

{"trap":"A question states: 'You need to prevent users from deleting other users' files in a shared directory. Which permission should you set?' The options include 'setuid', 'setgid', 'sticky bit', and 'umask'. Many learners choose 'umask' because they know umask controls default permissions, but it does not restrict deletion after the file is created.","why_learners_choose_it":"Learners often think that umask can solve any permission-related problem because it determines the permissions of newly created files and directories. They assume that if you set a restrictive umask, users cannot create files that others can delete. But umask only affects initial file creation; it does not enforce ownership-based deletion rules. A user can still delete any file in a writable directory regardless of umask.","how_to_avoid_it":"Understand the specific function of each permission mechanism. Umask sets default permissions but does not enforce runtime deletion restrictions. The sticky bit is the only mechanism that directly prevents unowned file deletion. In the exam, always ask yourself: 'What controls the ability to delete a file after it exists?' The answer is the sticky bit for directories. Practice with scenarios to build this instinct."}

## Commonly confused with

- **Sticky bit vs setuid bit:** The setuid bit allows a program to run with the permissions of the file owner, regardless of who executes it. It is used for privilege escalation (e.g., passwd command). The sticky bit does not change the effective user ID; it only restricts deletion in directories. They serve completely different purposes. (Example: The /usr/bin/passwd file has setuid (rwsr-xr-x) so any user can change their password as root. The /tmp directory has sticky bit (drwxrwxrwt) so users cannot delete each other's temp files.)
- **Sticky bit vs setgid bit:** The setgid bit on a directory causes new files created inside it to inherit the directory's group ownership, rather than the creator's primary group. This is useful for shared project directories. The sticky bit does not affect group inheritance; it only protects files from deletion by non-owners. They are often used together (e.g., 2770 for a shared directory with setgid and group rwx). (Example: A directory /project with permissions drwxrws--- (setgid) ensures all new files belong to the 'developers' group. If you also add the sticky bit (drwxrws--T or drwxrws--t), users cannot delete each other's files.)
- **Sticky bit vs Access Control Lists (ACLs):** ACLs provide fine-grained permissions beyond the traditional user-group-other model, allowing specific permissions for individual users or groups. The sticky bit is a single boolean flag that applies a simple rule to everyone. ACLs can replicate sticky bit behavior (by denying delete permission to others) but are more complex to configure. The sticky bit is simpler and standardized. (Example: If you want only user Alice to delete files in a directory, you could use an ACL to deny delete for everyone else. But the sticky bit does the same thing for all users except the owner, with a single command. ACLs are for more nuanced control.)

## Step-by-step breakdown

1. **Identify the target directory** — Decide which directory needs the sticky bit. Common candidates are /tmp, /var/tmp, shared project directories, or any world-writable directory where multiple users create files. Make sure the directory exists and you have root or appropriate permissions to change its mode.
2. **Check current permissions** — Use 'ls -ld /path/to/directory' to see the current permission string. Look at the last character of the 10-character string. If it is 't' or 'T', the sticky bit is already set. If it is 'x' or '-', the sticky bit is not set. Also note the owner and group so you do not accidentally change other settings.
3. **Set the sticky bit using symbolic mode** — Run 'chmod +t /path/to/directory'. The '+t' symbol adds the sticky bit without affecting other permissions. This is the safest method because it preserves existing read, write, and execute permissions. Verify with 'ls -ld', the last character should now be 't' (if execute was set) or 'T' (if execute was not set).
4. **Set the sticky bit using octal mode** — Alternatively, use octal mode by adding 1000 to the current permission number. For example, if the directory is currently 777, run 'chmod 1777 /path/to/directory'. If you want rwx for owner and group, and r-x for others, plus sticky, use chmod 1775. The leading 1 indicates the sticky bit. This method changes all permissions at once, so be careful to include the correct base permissions.
5. **Verify the sticky bit is applied** — Run 'ls -ld /path/to/directory' again. Confirm that the permission string ends with 't' or 'T'. For example, 'drwxrwxrwt' indicates the sticky bit is active and execute permission is set for others. Test the behavior by creating a file as one user, then trying to delete it as another user. You should receive an 'Operation not permitted' error.
6. **Remove the sticky bit if needed** — To remove the sticky bit, use 'chmod -t /path/to/directory'. This reverts the directory to standard permissions, allowing any user with write access to delete any file. Use with caution, especially on system directories like /tmp. Only remove it if you fully understand the security implications.

## Practical mini-lesson

The sticky bit is one of the three special Unix file permissions, alongside setuid and setgid. In practice, it is most often used on the /tmp directory. Every Linux distribution I have ever worked with has the sticky bit set on /tmp by default. If you install a fresh Ubuntu server and run 'ls -ld /tmp', you will see 'drwxrwxrwt'. This is not an accident, it is a critical security default.

When you are configuring a shared directory for a development team, you will typically combine the sticky bit with the setgid bit. The setgid bit ensures that new files inherit the group ownership of the directory, so all team members can edit each other's files (since they belong to the same group). The sticky bit then protects against accidental deletion. The command would be: chmod 2770 /shared/project and then chmod +t /shared/project. The final permissions would be 'drwxrws--T' (if no execute for others) or 'drwxrws--t' (if execute for others). The 's' in the group execute position indicates setgid is set.

One thing that can go wrong is that users might think the sticky bit grants them some kind of protection against themselves. No, the owner can always delete their own files. If a user accidentally deletes their own file, the sticky bit does not stop them. The sticky bit only prevents others from deleting that user's file. Another issue: if a directory has the sticky bit but the execute permission is missing for a user, they cannot list or traverse the directory at all. This is why /tmp typically has 777 with sticky bit, everyone needs to be able to access it.

Professionals also need to know that the sticky bit is respected by many system tools. The 'rm' command checks it. The 'mv' command checks it when renaming files across directories. The 'find' command does not bypass it. A user without ownership cannot use 'find -delete' to remove someone else's files in a sticky-bit directory. Even graphical file managers respect it because they call the same underlying system calls.

Another practical detail: when you create a user upload directory for a web application (like /var/www/uploads), you should set the sticky bit. Otherwise, if your web application runs as a different user for each virtual host (common with Apache's suEXEC or PHP-FPM pools), one user's upload script could potentially delete another's files. Setting the sticky bit prevents cross-account file deletion without needing complex ACLs.

Finally, remember that the sticky bit does not prevent a user from truncating or overwriting another user's file if they have write permission on that file. The sticky bit only protects against the deletion or renaming of the file entry in the directory. If the file itself grants write access to others, they can still modify its contents. So if you want full protection, you must also set restrictive file permissions.

## Memory tip

Sticky bit = "Sticky fingers", it stops others from taking your stuff. The 't' in permissions stands for "temporary" but think "tape", it holds your file in place.

## FAQ

**Can the sticky bit be set on files in Linux?**

Yes, you can technically set the sticky bit on a file using chmod, but on modern Linux kernels, it has no effect. The historical behavior (keeping the program in swap memory) is obsolete. Only the directory use of the sticky bit is relevant today.

**How do I check if the sticky bit is set on a directory?**

Use the command 'ls -ld directory_name'. Look at the last character of the permission string. If it is 't' or 'T', the sticky bit is set. For example, 'drwxrwxrwt' shows the sticky bit is active.

**Does the sticky bit prevent root from deleting files?**

No, the root user (superuser) bypasses all permission checks, including the sticky bit. Root can delete any file in a sticky-bit directory regardless of ownership.

**What is the difference between 't' and 'T' in the permission string?**

A lowercase 't' means the sticky bit is set and the execute permission is also set for others. An uppercase 'T' means the sticky bit is set but the execute permission is not set for others. Both provide the same deletion restriction, but the lack of execute permission may affect users' ability to traverse the directory.

**Can I set the sticky bit on a Windows system?**

Windows does not have a direct equivalent to the Unix sticky bit. However, Windows file systems use ACLs that can achieve similar results by setting specific deny rules on the delete permission. The concept is analogous but the implementation is different.

**Is it safe to remove the sticky bit from /tmp?**

No, it is not safe. Removing the sticky bit from /tmp would allow any user to delete any file in /tmp, which could lead to data loss, system instability, and security vulnerabilities. Always keep the sticky bit on world-writable directories like /tmp.

## Summary

The sticky bit is a special permission flag on Unix-like systems that protects files in a shared directory from being deleted or renamed by users who do not own them. It is a simple yet powerful security mechanism that enables safe multi-user environments. Without it, any user with write permission on a directory could destroy files created by others, leading to chaos in shared spaces like /tmp, project directories, and web upload folders.

For IT certification exams, the sticky bit is a core topic, especially in Linux-focused certifications such as CompTIA Linux+, LPIC-1, and RHCSA. You must know how to set it using both symbolic and octal commands, how to identify it in permission strings, and how it differs from setuid and setgid. You should also understand the historical context (file sticky bit) versus modern usage (directory only) to avoid exam traps.

In real-world system administration, the sticky bit is a default security setting that you will encounter daily. It is a best practice to apply it to any world-writable directory you create. Combined with setgid for group inheritance, it forms the foundation of secure shared directories. Understanding the sticky bit is not just about passing an exam, it is about being a competent and security-conscious IT professional who can protect user data in shared environments.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/sticky-bit