[llvm-dev] Experiment on how to improve our temporary file handing. (original) (raw)

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