OT: file operations atomicity

[Doug Barton]

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