Why everyone can write to /tmp - without creating chaos
One of those little Linux rules that quietly prevent chaos - and a lot of serious security problems.
Admins that come from the Windows world to Linux often ask me about the “deletion permission” for a file.
If you are already familiar with filesystem permissions on Linux, then you know of course that there isn’t really such a thing like a “permissions to delete a file”. Instead - it always comes down to the write permissions for the containing directory. If you have these permissions, you can delete the files.
That leads us to the “contradiction” I wanna show you here:
On a typical Linux system, every user can write to /tmp.
Which raises - with the knowledge from above - an interesting question:
Why can users usually not delete each other’s files there?
At first glance, this feels contradictory.
If everyone has write permissions for the directory, shouldn’t everyone be able to remove everything inside it too?
The interesting part is:
Linux behaves completely consistently here.
There’s just one small rule involved here that many people never really look at closely - even though it quietly affects nearly every shared directory on a Linux system.
Why write permissions alone would become a problem
If a user has write permissions for a directory, that user can usually:
- create files there
- rename files there
- remove files there
Even if the files themselves belong to someone else.
Because: If you remove a file from a directory, you are not changing the file contents - you are just removing the part of the directory, that points to this file.
About the /tmp problem
Now imagine what this would mean for /tmp.
Every user on the system creates temporary files there. Many processes do the same.
Without an additional rule, every user with write access to /tmp could remove everybody else’s temporary files too.
And if that wouldn’t introduce enough chaos on its own:
Think about the security implications, if you could delete another user’s file - and replace it with your own content instead.
This is exactly why on Linux systems there is usually an additional “permission” flag set for the /tmp directory: The “sticky bit”.
This little flag slightly changes the normal behavior:
Even if a user has write permissions for the directory itself, they can only remove files owned by that user.
That’s the only reason /tmp can stay world-writable without turning into complete chaos or a security nightmare.
A practical demonstration
Let me show you what this looks like in practice.
One small rule - but an important mental model
What I personally like about examples like this is:
Once you understand them, Linux suddenly stops feeling random.
A behavior becomes understandable once you know which part of the system actually controls it.
And often the individual rules themselves are not even complicated. Many of them are simply not part of our “day-to-day” work, so they never manifest themselves in our knowledge “just from doing”. And therefore, we cannot always clearly see the interaction between them.
That’s also why troubleshooting can become frustrating sometimes.
We often look at one layer of the system - while the actual behavior we see is caused somewhere else.
LinuxBOSS
This way of thinking is a big part of what I focus on in LinuxBOSS.
Not just memorizing commands or “how to do X” - but understanding how Linux systems actually behave internally.
So troubleshooting becomes calmer, systems become more predictable, and the moving parts start fitting together more naturally.
👉 Take a look at LinuxBOSS
