The sticky bit is a special permission flag that, when set on a directory, allows a file inside it to be deleted or renamed only by the file’s owner, the directory’s owner or root, even though other users have write permission on the directory. In Linux permissions, it is the mechanism that makes shared directories such as /tmp safe for many users at once.
It is one of three special mode bits alongside setuid and setgid. In octal notation it has the value 1000, and in symbolic listings it appears as a t in the last position of the permission string, as in drwxrwxrwt.
Why directories need the sticky bit
Standard Unix file permissions contain a subtle rule: deleting or renaming a file is an operation on the directory, not on the file. Any user with write and execute permission on a directory can remove any file in it, regardless of who owns the file or what its own permissions are.
For a private directory this rule is harmless, but a world-writable shared directory would let every user delete or replace everyone else’s files. The sticky bit adds a restricted deletion rule to the directory: write permission still allows creating files, but removing or renaming an entry additionally requires owning the file or the directory, or having root privileges.
| User | Without sticky bit | With sticky bit |
|---|---|---|
| File owner | Can delete | Can delete |
| Directory owner | Can delete | Can delete |
| Root or CAP_FOWNER holder | Can delete | Can delete |
| Any other user with write access | Can delete | Cannot delete or rename |
Setting and reading the sticky bit
The sticky bit is set with chmod, either symbolically or in octal form. In the octal form, it is the leading digit of a four-digit mode, where 1 means sticky, 2 means setgid and 4 means setuid.
| Command | Effect | Resulting listing |
|---|---|---|
chmod +t shared | Adds the sticky bit | drwxrwxrwt if others have execute |
chmod -t shared | Removes the sticky bit | drwxrwxrwx |
chmod 1777 shared | Full access for all plus sticky bit | drwxrwxrwt |
chmod 1770 shared | Owner and group access plus sticky bit | drwxrwx--T |
stat -c %a shared | Shows the octal mode | 1777 |
The letter in the listing carries meaning. A lowercase t means the sticky bit is set and others also have execute permission. An uppercase T means the sticky bit is set but others lack execute permission, which usually indicates an unintended or incomplete configuration on a directory meant for everyone, although it is valid for a group-only shared directory.
Sticky bit compared with setuid and setgid
The three special bits share the extra octal digit but serve completely different purposes. Confusing them is a common source of permission mistakes.
| Bit | Octal value | Effect on files | Effect on directories |
|---|---|---|---|
| setuid | 4000 | Program runs with the file owner’s privileges | Ignored on Linux |
| setgid | 2000 | Program runs with the file group’s privileges | New files inherit the directory’s group |
| Sticky bit | 1000 | Ignored by modern Linux | Restricted deletion and renaming |
Collaborative directories often combine setgid and sticky with mode 3770: setgid keeps new files in the shared project group, and the sticky bit stops members from deleting each other’s work. Default permissions of new files in such directories are still governed by the creating user’s umask, and finer per-user rules require a Linux ACL.
History and current behavior on Linux
The name comes from early Unix, where the bit was applied to executable files. It told the kernel to keep the program’s text segment in swap space after it exited, so frequently used programs stuck in memory and started faster. With demand paging and modern virtual memory, this purpose became obsolete, and the Linux kernel ignores the sticky bit on regular files.
Linux also adds protections related to sticky directories. With the kernel settings `fs.protected_symlinks` and `fs.protected_regular`, enabled by default on most distributions, the kernel restricts following symbolic links and opening existing files owned by other users in sticky world-writable directories. These measures defend against classic temporary file race attacks.
| Directory | Usual mode | Purpose |
|---|---|---|
| /tmp | 1777 | Temporary files for all users |
| /var/tmp | 1777 | Temporary files preserved across reboots |
| /dev/shm | 1777 | Shared memory objects |
| /var/spool/cron or similar spools | Varies by distribution | Per-user queued jobs |
Common mistakes
- Creating a world-writable directory without the sticky bit, which lets any user delete or replace other users’ files.
- Setting mode 777 instead of 1777 when restoring
/tmp, for example after a restore from backup or a manual recreation. - Expecting the sticky bit to protect file content: it controls deletion and renaming, while reading and writing still follow the file’s own permissions.
- Applying it to regular files and expecting an effect; on Linux it does nothing there.
- Relying on it against root: root and processes with the CAP_FOWNER capability can always delete files.
Auditing for world-writable directories without the sticky bit is a standard hardening check. A command such as find / -xdev -type d -perm -0002 ! -perm -1000 lists candidates that should be reviewed.
The idea in brief
Imagine a shared fridge in an office. Everyone may put food in it. Without a rule, anyone could also throw away someone else’s lunch.
The sticky bit is that rule for shared folders on a computer. Everyone can add files, but only the person who put a file there can remove it. The owner of the folder and the system administrator are the only exceptions. This keeps shared spaces useful and fair for everyone.
A practical scenario
A university runs a Linux server where 200 students upload assignment drafts to a shared directory, /srv/dropbox. Initially the directory has mode 0777, and one day a student’s script cleans up “old files” and deletes the drafts of dozens of classmates.
The administrator changes the directory to mode 1777 with chmod 1777 /srv/dropbox. Students can still create files, but an attempt to delete someone else’s file now fails with “Operation not permitted”. A periodic hardening scan is added to find other world-writable directories missing the sticky bit, and two more are fixed. Since the change, no student has been able to remove another student’s work, while the shared upload workflow remains as simple as before.