Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
On 22/02/11 19:54, Ben Hutchings wrote:
Judging by what you consider 'small bugs' in
why should anyone trust their important data to this library?
Feel free not to use it/file bugs against it. Giving feedback over the
upstream trustworthiness is not the purpose of ITP bugs, and I have been
warned by the list masters that discussing a specific package's upstream
bugs on Debian-devel is off topic.
I quickly reviewed the code and found:
Did you read the accompanying manual pages first?
safe_open() might not return correct error codes, since the library
and system calls in its cleanup code may overwrite the original error
Thank you for your input. I'll fix it.
It uses a fixed extension for the temporary file name, and unlinks
whatever was there before; this could be a security flaw.
The matter has been discussed before. If you have a specific scenario
where this will cause a security flaw, please feel free to file a bug or
contact me directly. Pending that happening, my analysis is that there
is no security flaw in that case.
It doesn't check for failure of fstat() (this is unlikely but possible,
e.g. when using a network filesystem).
Interesting point. I'll have to think about it.
Copying setuid and setgid bits to an empty file is pointless, since
they are cleared by write() (this is a good thing!).
Frankly, I was not aware of this. I could not find it documented in the
man pages. In any case, this is no regression from the non-safe_open
case, as these would get cleared on write either way. If this is a Linux
only feature, I'm actually inclined to leave the code in (which is why I
needed the manual pages).
safe_close() doesn't actually close the file or free the 'context' if
fsync() fails. This is inconsistent with close().
But consistent with what the man page says about it. The alternative is
to not allow the user to retry saving the file's content, which I don't
see as preferable.
Thank you for your feedback.
Lingnu Open Source Consulting Ltd.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org