Temporary files, security - and filesystem transactions

It is well known that temporary files can be security holes.

Hence

mkstemp(3)

which generates a unique temporary file name, creates and opens the file, and returns an open file descriptor for the file.

"Atomically".



But this may not be enough.

E.g. today I am trying to replace a file with a new file generated from it - by creating a temporary, and then renaming.



Problem:

* I can't rename the file  specified by a file descriptor

* if I rename the file

   * on Linux, the name may have been reused, since Linux allows files to be removed even though open

   * on cygwin, cannot rename if open. but if I close the handle, then the bad guy may be able to race and intercept



We can discuss kluges for this specific case:

* e.g. rename a file specified by descriptor



But the more general problem is

* atomicity

* and the fact that temporary filenames are globally visible.



If the temporary filename were not globally visible, then could securely



      create tmp

      write tmp

      close tmp

      rename tmp



with confidence that nobody else is squeezing between.



More generally, if we had filesystem transactions to guarantee atomicity



      BEGIN TRANSACTION

      create new file1, file2

      write new file1, file2

      close new file1, file2

       abort if error

     END TRANSACTION



Then we can create multiple such files, without having to mess with temporary filenames,

and without having to rename the temporary filenames to the official filenames.

We can use the official filenames from the get-go.



I.e. filesystem transactions automatically create secure hidden temporary files.

Without error prone programming.



---



The same may apply to shared memory transactions - but is most interesting when the shared memory has fine grain access control, e.g. capabilities, rather than the "shared-memory = security hole" we have nowadays.