Debian Bug report logs - #614601
RFP: libsafewrite -- Simple functions for performing safe atomic replacement of files

Package: wnpp; Maintainer for wnpp is wnpp@debian.org;

Reported by: Shachar Shemesh <shachar@debian.org>

Date: Tue, 22 Feb 2011 15:09:01 UTC

Severity: wishlist

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, debian-devel@lists.debian.org, wnpp@debian.org:
Bug#614601; Package wnpp. (Tue, 22 Feb 2011 15:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Shachar Shemesh <shachar@debian.org>:
New Bug report received and forwarded. Copy sent to debian-devel@lists.debian.org, wnpp@debian.org. (Tue, 22 Feb 2011 15:09:04 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Shachar Shemesh <shachar@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Date: Tue, 22 Feb 2011 16:41:15 +0200
Package: wnpp
Severity: wishlist
Owner: Shachar Shemesh <shachar@debian.org>


* Package name    : libsafewrite
  Version         : 1.00
  Upstream Author : Shachar Shemesh <shachar@lingnu.com>
* URL             : http://www.lingnu.com/opensource/safewrite.html
* License         : MIT
  Programming Lang: C
  Description     : Simple functions for performing safe atomic file updates

Safewrite is a library for simple, almost drop-in replacement to the usual
open and close calls. Using safewrite, however, guarantees that the files be
updated in an atomic way - anyone trying to read the file is guaranteed to get
a complete version, either the old or the new, but never a partially updated
file.




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Shachar Shemesh <shachar@debian.org>:
Bug#614601; Package wnpp. (Tue, 22 Feb 2011 17:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ben Hutchings <ben@decadent.org.uk>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Shachar Shemesh <shachar@debian.org>. (Tue, 22 Feb 2011 17:57:05 GMT) Full text and rfc822 format available.

Message #10 received at 614601@bugs.debian.org (full text, mbox):

From: Ben Hutchings <ben@decadent.org.uk>
To: Shachar Shemesh <shachar@debian.org>, 614601@bugs.debian.org
Cc: debian-devel@lists.debian.org
Subject: Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Date: Tue, 22 Feb 2011 17:54:50 +0000
On Tue, Feb 22, 2011 at 04:41:15PM +0200, Shachar Shemesh wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Shachar Shemesh <shachar@debian.org>
> 
> 
> * Package name    : libsafewrite
>   Version         : 1.00
>   Upstream Author : Shachar Shemesh <shachar@lingnu.com>
> * URL             : http://www.lingnu.com/opensource/safewrite.html
> * License         : MIT
>   Programming Lang: C
>   Description     : Simple functions for performing safe atomic file updates
> 
> Safewrite is a library for simple, almost drop-in replacement to the usual
> open and close calls. Using safewrite, however, guarantees that the files be
> updated in an atomic way - anyone trying to read the file is guaranteed to get
> a complete version, either the old or the new, but never a partially updated
> file.

Judging by what you consider 'small bugs' in
<https://github.com/Shachar/safewrite/commit/efafcd4260375a41257709c7eb5a8d6065366849>
why should anyone trust their important data to this library?

I quickly reviewed the code and found:

safe_open() might not return correct error codes, since the library
and system calls in its cleanup code may overwrite the original error
code.

It uses a fixed extension for the temporary file name, and unlinks
whatever was there before; this could be a security flaw.

It doesn't check for failure of fstat() (this is unlikely but possible,
e.g. when using a network filesystem).

Copying setuid and setgid bits to an empty file is pointless, since
they are cleared by write() (this is a good thing!).

safe_close() doesn't actually close the file or free the 'context' if
fsync() fails.  This is inconsistent with close().

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
                                                              - Albert Camus




Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org:
Bug#614601; Package wnpp. (Wed, 23 Feb 2011 04:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Shachar Shemesh <shachar@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org. (Wed, 23 Feb 2011 04:12:03 GMT) Full text and rfc822 format available.

Message #15 received at 614601@bugs.debian.org (full text, mbox):

From: Shachar Shemesh <shachar@debian.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: 614601@bugs.debian.org, debian-devel@lists.debian.org
Subject: Re: Bug#614601: ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
Date: Wed, 23 Feb 2011 05:51:05 +0200
On 22/02/11 19:54, Ben Hutchings wrote:

>
> Judging by what you consider 'small bugs' in
> <https://github.com/Shachar/safewrite/commit/efafcd4260375a41257709c7eb5a8d6065366849>
> 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
> code.
>    
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

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com





Information forwarded to debian-bugs-dist@lists.debian.org, wnpp@debian.org, Shachar Shemesh <shachar@debian.org>:
Bug#614601; Package wnpp. (Mon, 27 May 2013 14:13:12 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@debian.org>:
Extra info received and forwarded to list. Copy sent to wnpp@debian.org, Shachar Shemesh <shachar@debian.org>. (Mon, 27 May 2013 14:13:12 GMT) Full text and rfc822 format available.

Message #20 received at 614601@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@debian.org>
To: 614601@bugs.debian.org
Cc: control@bugs.debian.org
Subject: libsafewrite: changing back from ITP to RFP
Date: Mon, 27 May 2013 15:24:13 +0200
retitle 614601 RFP: libsafewrite -- Simple functions for performing safe atomic replacement of files
noowner 614601
tag 614601 - pending
thanks

Hi,

This is an automatic email to change the status of libsafewrite back from ITP
(Intent to Package) to RFP (Request for Package), because this bug hasn't seen
any activity during the last 12 months.

If you are still interested in adopting libsafewrite, please send a mail to
<control@bugs.debian.org> with:

 retitle 614601 ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files
 owner 614601 !
 thanks

However, it is not recommended to keep ITP for a long time without acting on
the package, as it might cause other prospective maintainers to refrain from
packaging that software. It is also a good idea to document your progress on
this ITP from time to time, by mailing <614601@bugs.debian.org>.

Thank you for your interest in Debian,
-- 
Lucas, for the QA team <debian-qa@lists.debian.org>



Changed Bug title to 'RFP: libsafewrite -- Simple functions for performing safe atomic replacement of files' from 'ITP: libsafewrite -- Simple functions for performing safe atomic replacement of files' Request was from Lucas Nussbaum <lucas@debian.org> to control@bugs.debian.org. (Mon, 27 May 2013 14:26:31 GMT) Full text and rfc822 format available.

Removed annotation that Bug was owned by Shachar Shemesh <shachar@debian.org>. Request was from Lucas Nussbaum <lucas@debian.org> to control@bugs.debian.org. (Mon, 27 May 2013 14:26:31 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 16:24:36 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.