Sven Radde wrote: > Hi! > > Andrew Flerchinger schrieb: >>> 1. Use mktemp to safely create a new, unique file >>> 2. Send the decryption output to that file >>> 3. Test if the "real" file exists, and if so unlink it >>> 4. mv $newfile $realfilename >>> >> You're right, I could do that to make my work-around act atomic. > > Be careful, this is not necessarily atomic. You're assuming transactions > where no such thing exists.
I noticed that you were replying to Andrew, but FWIW I very carefully avoided using the word "atomic" in my post, for good reason. > If the system crashes in the wrong moment, you would have the real file > unlinked and the renaming has not yet taken place. It might even be the > case that the tempfile is not even persisted to disc. True, although you're talking millisecond timing it could happen. OTOH, if untrusted users are allowed on the system the old "symlink a harmless file to an important file so that the latter can be splattered by an automated process" is a long-known vulnerability that can easily be defended against. On the _other_ other hand, I left out the whole discussion about "What is your threat model?" and, "What is the value of the data relative to the amount of work you're willing to spend protect it?" It's also worth noting that even if the new decrypted file is lost before the old decrypted file is replaced, it's likely that you still have the clear original to work from so we're not talking about a catastrophic data loss. If we were concerned about destroying the clear original immediately after the new encrypted version is created then you would at minimum want to get the new version onto the same file system as the old one before you started removing things. > I am not making this up ... I believe you. :) My purpose was more to get the OP thinking in terms of better procedures for an automated process, and to try to point out that the current behavior of gnupg doesn't seem to be a bug. hth, Doug _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
