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.
Disclaimer
The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.
Subscribe to:
Posts (Atom)