Protecting Shared Spaces
What if you have a directory like /tmp where everyone needs to be able to create files, but you don't want users deleting each other's work?
If you give a directory rwx permissions for "Others" (chmod 777 /tmp), anyone can delete anything inside it, even files they don't own. This is dangerous for shared temporary spaces.
The solution is the Sticky Bit. When set on a directory, it adds a special rule: Only the file's owner, the directory's owner, or root can delete or rename that file. Other users can still read and write to the file if its individual permissions allow, but they cannot remove it from the directory.
The sticky bit is set symbolically (chmod +t) or as a leading 1 in four-digit octal (chmod 1777), and appears as a t in the others' execute position of the permission string — /tmp itself typically shows drwxrwxrwt. If the directory doesn't have execute permission for others, it shows as T (uppercase) instead of t — a capital letter always means the special bit is set but the corresponding execute bit is missing, making the special bit ineffective.
Real-world example: in a shared directory with the sticky bit set and full read/write/execute for everyone, one user creating a file there and a second, unrelated user attempting to delete it will be refused with "Operation not permitted" — even though that second user has write permission on the directory itself. The sticky bit overrides the usual rule that directory-write implies the ability to delete, for anyone but the file's owner, the directory's owner, or root.
Key Point: The sticky bit is essential for any shared writable directory in production. Without it, a malicious or careless user could delete critical files. Always use
chmod 1777(orchmod +t) for directories like/tmp,/var/tmp, and any shared upload or cache directories. In Kubernetes, when usingemptyDirvolumes shared between containers in a pod, consider whether you need the sticky bit to prevent one container from deleting another's files.