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.
