Re: Where to report: root fails to edit other users file in sticky bit directory
On Tue, Dec 08, 2020 at 09:50:32PM +0100, MichaIng wrote:
> And, root should IMO still be allowed to do it, as practically it can anyway
> via chown. root can as well remove any file, regardless of sticky bit, so
> this would be consistent.
Unexpected clobberin' by root is the actual *worst* case that this
security feature is trying to protect against. Imagine this hypothetical
scenario:
1) Process A running as regular user alice creates a temp file in /tmp,
owned by alice.
2) Dumb process B running as root decides to use the exact same temp file
name that A is using. It opens the file naively, and writes some
stuff to it, intending to read it back later.
3) Process A rewinds the file and writes new stuff to it.
4) Process B reads process A's data from the file, thinking it was going
to read its own data.
5) Process B calculates the wrong thing, and turns off the life support
system.
I don't know how realistic this is, or how closely it mirrors the thought
processes of the people who came up with the modification. But if you're
going to make this modification at all, it needs to affect root, or else
it's pointless.
Your unique situation, where user A is putting a file in /tmp for some
reason, and then user R is supposed to edit it in place, is really weird.
I don't know why you're putting this important shared file in /tmp, but
you might want to move it to a more appropriate place.
Reply to: