[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
it's pointless.

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 without O_CREAT.

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).

Best regards,


Reply to: