Re: Where to report: root fails to edit other users file in sticky bit directory
On Wed, Dec 09, 2020 at 12:02:17AM +0100, MichaIng wrote:
> Sharing files through /tmp is probably rare, but /tmp it is for temporary
> files, it's by default a tmpfs
No, it's not. It's just a directory inside the root file system by
default, in Debian.
> (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.
*sigh* Another person confused by FHS.
FHS is not for *you*. It's for your *vendor*. It's your vendor's
problem to worry about. Your vendor in this case is Debian. Only Debian
has to worry about this crap.
YOU, the system administrator, or application developer, can put your
files any place you want. Make a directory that is in a sane place,
with sane ownership and permissions (to prevent malicious users from
causing the EXACT PROBLEM that this security change is trying to work
around!), and store your data there.
If you somehow feel that you must conform to the FHS despite not being
a Linux distributor, then I would recommend /var/cache/yourapp/. Or
if the files are small and persistence is not desired, you could make a
directory under /run, which actually *is* a tmpfs by default, unlike /tmp.
A shared /tmp is simply a horrible design on a multi-user system. It
was a simple thing to implement back in the days of olde, I'm sure, but
it really has caused a plethora of real life problems.
Reply to: