[llvm-dev] Experiment on how to improve our temporary file handing.
Rafael Avila de Espindola via llvm-dev
llvm-dev at lists.llvm.org
Tue Nov 14 08:33:22 PST 2017
Konstantin Belousov <kostikbel at gmail.com> writes:
> This is quite different request from O_TMPFILE. The tmpfile can be
> implemented in a day or two for UFS. The ability to enter the inode
> referenced by a file descriptor, into the filesystem namespace at a
> given location, was proposed several times and rejected, I believe. The
> cause is that it potentially allows to gain additional access rights.
>
> Imagine that a process obtained a file descriptor only opened for read,
> e.g. by passing over unix domain socket. If it is possible to link
> its inode, you can re-open it limited by access permissions on the
> inode. Inode may have rw rights, but its current containing directory
> disallowing the walk.
Thanks. I had seen security concerns mentioned before, but never an
actual example.
> This is especially important for capabilities-based sandbox environments,
> like capsicum.
Yes. I guess a "link" capability would be needed and for backwards
compatibility open would normally not return an fd with it.
>> A system with O_TMPFILE which allows some form of renameat to
>> atomically give that fd a name would be perfect.
> I believe that #2 is not that critical.
Not critical, just very convenient.
A power failure is just the extreme case. The more common issue is
making sure that every code path removes or renames the temp file,
including signals terminating the program.
Having a temp file without a name or one that is deleted on close (like
on windows) would make the solution trivial.
Cheers,
Rafael
More information about the llvm-dev
mailing list