0 / 4
Sticky Bit
On Linux, whether you can delete a file depends not on the file's own permissions but on write permission for the directory that holds it. Deleting a file actually removes its name from the directory's file list. So in a shared directory where every user has write permission, you can delete other people's files too. The sticky bit is the special permission that prevents this.
Example: Bob tries to delete a file that Alice created in the shared directory /shared.
1 / 4
Alice: create a file
Alice creates alice.txt in /shared. That works because every user has write permission on the directory. The file's owner is Alice and its mode is rw-r--r--. Only Alice can change its contents, and other users can only read it.
2 / 4
Bob: delete alice.txt
Bob runs a command to delete alice.txt. Bob isn't the owner, so the file's permissions only allow reading. But the OS doesn't look at the file's permissions when deciding whether it can be deleted. The -f option deletes without asking.
3 / 4
OS: check the directory permissions
The OS looks at the permissions of /shared. Bob isn't the directory owner (root) and isn't in the root group, so the others class applies. That class has write (w), so Bob can create and delete files in this directory. The execute slot shows x, not t, so there is no sticky bit either. The OS moves on without checking who owns the file.
4 / 4
Result: Alice's file is deleted
The name alice.txt is removed from the directory list, and the file is gone. Alice, the owner, never allowed it. In a shared directory without the sticky bit, however tightly you set file permissions, you can't stop others from deleting files.
1 / 5
Alice: create a file
Alice creates alice.txt in /tmp. Anyone can still create files when the sticky bit is set. Only deleting or renaming other people's files is blocked.
2 / 5
Bob: delete alice.txt
Bob tries to delete alice.txt with the same command as in the previous tab.
3 / 5
OS: check the owner
Bob has write permission on the directory. But the others execute slot shows t, so the sticky bit is set. The OS then checks whether Bob is the file owner, the directory owner or root. Bob is none of these.
4 / 5
Result: deletion denied
The OS refuses and returns an “Operation not permitted” error. The file alice.txt stays where it is. Renaming it with mv is refused the same way.
5 / 5
Bob: delete bob.txt
The file bob.txt belongs to Bob, so it is deleted as usual. The same goes when Alice deletes alice.txt or root deletes any file. The sticky bit doesn't stop anyone from deleting their own files.
1 / 4
Split the ten characters
The leading d means a directory. The other nine characters are the permissions of the owner, the group and others, three at a time. Others means every user who is neither the owner nor in that group. A slot without a permission shows -.
2 / 4
Setting the sticky bit: t
The root user sets the sticky bit with chmod +t. The x in the others execute slot changes to a lowercase t. A lowercase t appears when both execute permission and the sticky bit are set.
3 / 4
In octal: 1777
In octal, put a 1 in front of the permission digits 777, as in chmod 1777. The leading digit is for special permissions, and 1 is the sticky bit. A 4 there sets SetUID and a 2 sets SetGID, which are other special permissions.
4 / 4
No execute permission: T
Setting the sticky bit without execute permission for others (chmod 1776) shows that slot as an uppercase T. It is a lowercase t with execute permission and an uppercase T without.