Sticky Bit

Expanded Definition

The sticky bit is a Unix and Linux directory permission that changes how deletion and renaming behave inside a shared writable directory. Rather than granting broader administrative power, it preserves file ownership boundaries so that a user can only remove or rename items they own, unless they are the directory owner or root. That makes it especially useful in common multi-user locations such as temporary directories, spool areas, and collaboration folders where write access is intentionally broad but file integrity still needs protection.

In modern security terms, the sticky bit is a narrow access control safeguard, not a general hardening control. It does not stop users from reading files they can already access, and it does not replace least privilege, filesystem ACLs, or proper ownership design. It is also not a permission you apply to arbitrary regular files in the same way people sometimes assume. Guidance varies across administrative documentation, but the operational meaning is consistent: it is about controlling deletion authority inside directories, not about encrypting data or isolating process execution.

The most common misapplication is treating the sticky bit as a substitute for ACLs, which occurs when administrators expect it to prevent all unwanted access in shared directories.

Examples and Use Cases

Implementing the sticky bit rigorously often introduces a small administration constraint, requiring teams to balance convenience in shared folders against tighter file-deletion control.

• Shared temporary directories such as NIST Cybersecurity Framework 2.0-aligned Linux systems often use the sticky bit on /tmp so one user cannot delete another user’s files.
• Multi-user application drop zones use it to allow uploads while preventing accidental or malicious removal by other contributors.
• Print spool or job queue directories rely on it so users can submit items without being able to interfere with other users’ queued files.
• Collaboration directories on shared servers use it when ownership needs to remain enforceable even though write access is open to a group.
• Security administrators verify it during baseline reviews because missing sticky-bit protection in writable directories can turn routine shared spaces into easy tampering points.

Why It Matters for Security Teams

The sticky bit matters because shared writable directories are common attack and misuse surfaces. Without it, any user with write permission could delete or rename someone else’s files, which can create denial-of-service conditions, destroy work products, or disrupt software workflows. That risk is especially relevant in environments with many local users, automation accounts, or ephemeral workloads.

For security teams, the sticky bit is a simple but important example of how filesystem permissions support operational containment. It sits alongside ownership, group design, and access control policy, rather than replacing them. In identity-heavy environments, the lesson is similar to NHI governance: write access alone should not imply full control over shared resources. Tooling can create the appearance of shared productivity while still needing strict boundaries underneath.

Organisations typically encounter the impact of a missing sticky bit only after files disappear from a shared directory, at which point the permission becomes operationally unavoidable to address.

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?