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.