[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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.

Shachar Shemesh
Lingnu Open Source Consulting Ltd.

Reply to: