Re: Where to report: root fails to edit other users file in sticky bit directory
Am 08.12.2020 um 22:03 schrieb Greg Wooledge:
Unexpected clobberin' by root is the actual *worst* case that this
security feature is trying to protect against. Imagine this hypothetical
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
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
Such a (custom) process should simply not run as root, should create an
own temporary sub directory with limited permissions and write it's own
files there. If really something is written to the world-writeable /tmp
directory root, it must be expected that it can be read and written to
or created by other users. Btw. the way the security feature is
implemented, explicitly allows anyone writing to the file (as long as
UNIX permissions are given), so it does not totally rule out your
scenario, but only when process B uses a O_CREAT access method. But it
could instead check if the file exists first, and otherwise write to it
But I got the point, as especially root processes are likely more
sensitive and create larger damage when manipulated (accidentally or
intentionally) such a way.
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.
There is no reason to use the /tmp root (without sub directory) aside of
expecting that the file is potentially shared, IMO. If it must only be
accessed by the same process/user, it should be placed elsewhere, at
least into a sub directory or a private /tmp.
Sharing files through /tmp is probably rare, but /tmp it is for
temporary files, it's by default a tmpfs (relevant when one wants to
minimize file system writes, e.g. drive spin up or SD cards with short
life cycle, or runs a R/O system), and it's the only FHS directory that
is world-writeable by default. So I cannot imagine any better place to
share temporary information through files cross-process/user then /tmp :D.
So yeah, basically the feature prevents users, who do not know what they
are doing, from rare but possible errors and attacks, but it limits
users, who know that they are doing, from rarely relevant possibilities
xD. I think it is all fine as long as it's well documented, i.e. part of
docs and man pages that deal with the sticky bit, like man chmod(1).