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


More information about the llvm-dev mailing list