Sticky Bit

What the sticky bit does in Linux permissions

The sticky bit is a directory-level permission that changes who can remove or rename entries inside a shared writable directory. Without it, write access alone can let one user delete another user's files in the same location, so the control is most often used where many accounts need shared write access but not shared deletion power.

In practice, the sticky bit is a narrow but important protection for collaboration spaces such as temporary directories, drop zones, spool locations, and other multi-user write paths. It does not restrict reading or writing by itself; it specifically limits destructive namespace operations, which is why it is paired with ordinary permission bits rather than replacing them.

How deletion control works in shared directories

When the sticky bit is set on a directory, the operating system checks ownership before allowing a file to be removed or renamed. The file owner, the directory owner, or root can act on the entry, even when other users have write access to the directory. That makes the permission especially useful in places where the directory must stay open to many users, but individual users still need protection for their own files.

This behaviour matters because directory write permission and file ownership solve different problems. A writable directory lets users create or modify entries, while the sticky bit preserves individual ownership boundaries for existing files. The result is a shared workspace that remains operational without giving everyone the ability to interfere with everyone else's files.

Why /tmp and similar paths rely on it

Shared system directories are the classic use case because they are both heavily used and easy to abuse. A world-writable directory without the sticky bit can become a place where one user removes another user's temporary files, breaks application workflows, or interferes with service scratch space. That is why hardened Linux systems typically treat the sticky bit on public write directories as a basic safety requirement rather than an optional convenience.

NHI Management Group's Linux Fundamentals for Defenders Guide places the sticky bit in the wider context of Linux users, permissions, sudo, and system hardening, while Linux File Permissions, SUID and ACLs Guide shows how sticky bits sit alongside mode bits, setuid, setgid, ACLs, and audit monitoring.

Operational consequences and common misunderstandings

The sticky bit is often misunderstood as a general file protection feature, but its scope is much narrower. It does not make a file unreadable, it does not encrypt content, and it does not stop the owner of the file from changing it. Its purpose is to protect directory entries in collaborative locations, which means its value depends on the directory being shared and writable in the first place.

It is also easy to assume that any permission problem can be solved with the sticky bit. That is not true. If the issue is excessive write access, unsafe ownership, or a badly designed shared directory layout, the sticky bit helps only at the deletion boundary. It is a containment control, not a substitute for proper directory ownership, least privilege, or sensible filesystem design.

Risk and Threat Considerations

Where shared writable directories exist, the main risk is uncontrolled deletion, renaming, or substitution of files by another local user. That can disrupt applications, break workflows, and create a foothold for simple abuse of trust in multi-user environments.

Failure mechanism: If a shared directory is writable but not sticky, any user with directory write access may be able to remove or rename another user's entries, because the namespace is not protected at the entry level.

Impact: The result can be data loss, service disruption, tampering with temporary files, and unexpected application failures, especially in directories that act as scratch space or inter-process handoff points.

Practitioner Guidance

What to watch for: Treat the sticky bit as mandatory on any directory that is intentionally writable by multiple users, especially temporary and shared spool locations. If a directory must be collaborative, verify that the permission model still preserves file ownership boundaries instead of relying on write access alone.

Practitioner takeaway: The sticky bit is a small control with a very specific job, but in shared directories it is often the difference between safe collaboration and one user's ability to damage another user's work.

Related resources from NHI Mgmt Group

• What breaks when an Office kill bit is bypassed by a malicious document?
• How should security teams phase out 1024-bit encryption without breaking production services?
• What breaks when MCP clients and servers still assume sticky sessions?
• What breaks when Fluent Bit tags are allowed to control routing and file output?