Bug#607267: /usr/bin/scp: fails to notice close() errors
severity 607267 important thanks On Thu, Dec 08, 2011 at 02:33:00PM +0100, Michal Suchanek wrote: FWIW this is unreproducible as of kernel 3.2 rc2 so I guess this is squeeze only for cifs shares (as can be verified by running the test on a squeeze live CD). Thanks for reporting. Given the small amount of systems being able to reproduce this issue I am downgrading the severity. You need an old (or stable) kernel and a filesystem like cifs. This doesn't seem to be a frequently encountered combination. However, the close() man page clearly states that only doing fsync() you can be sure your file was closed successfully. This is slightly incorrect. If close() returns 0, the file is closed successfully, so unfortunately your immediate conclusion is wrong again. The truth is that close() does not ensure that any data has reached a disk. Also note that using fsync() would not be enough either. It would just force the file to disk, but not necessarily its entry in a directory. After a power failure your file would be on the disk, but there would be no visible reference from your directory tree. You'd have to call fsync on the directory as well. After all it doesn't seem that obvious given that you got it wrong. ;-) I still wonder where it says that cp would guarantee that data would reach a disk. Can you find a reference? Same question for scp. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#607267: /usr/bin/scp: fails to notice close() errors
Processing commands for cont...@bugs.debian.org: severity 607267 important Bug #607267 [openssh-client] /usr/bin/scp: fails to notice close() errors Severity set to 'important' from 'grave' thanks Stopping processing here. Please contact me if you need assistance. -- 607267: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607267 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
FWIW this is unreproducible as of kernel 3.2 rc2 so I guess this is squeeze only for cifs shares (as can be verified by running the test on a squeeze live CD). If there are other filesystems that might produce the same behaviour under some circumstances in current kernel I don't know. However, the close() man page clearly states that only doing fsync() you can be sure your file was closed successfully. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hi Michal, On Mon, Dec 05, 2011 at 12:41:21AM +0100, Michal Suchanek wrote: Excerpts from Helmut Grohne's message of Sat Dec 03 17:33:04 +0100 2011: Hi, On Sun, Jan 02, 2011 at 03:48:05PM +0100, Michal Suchanek wrote: This same issue also happens with cp(1) from coreutils. I verified that this statement is wrong. It is not. This probably depends on the point of view. From the current context it is not clear what this issue is. Please read the analysis in the latter message. I think we should split this up in two issues: 1) Not checking the return value of close(). This is a very real bug in openssh, but not in coreutils (seem my analysis). 2) Not fsyncing the files before closeing them. It is not the job of cp nor scp to guarantee that any file has reached the disk. So this bug will not be fixed. If it was their job, tools like sync(1) would not exist in the first place. If it was, you could file this bug report against every single package handling files in the archive (except for a handful). Since that would be insane, I simply dropped this request in my previous reply. I should have made this more explicit. Can we now ignore 2) and concentrate on 1)? A quick grep of the openssh source indicates that checking close is overrated. Who needs errors anyway? I want that it works!!1!eleven And for it to work it needs to report errors when they happen. I guess I should have used explicit irony tags here. Unfortunately fixing ssh will not be a small patch. It might be best to simply document the issue in man 1 scp. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Excerpts from Helmut Grohne's message of Mon Dec 05 15:54:19 +0100 2011: Hi Michal, On Mon, Dec 05, 2011 at 12:41:21AM +0100, Michal Suchanek wrote: Excerpts from Helmut Grohne's message of Sat Dec 03 17:33:04 +0100 2011: is not clear what this issue is. Please read the analysis in the latter message. I think we should split this up in two issues: 1) Not checking the return value of close(). This is a very real bug in openssh, but not in coreutils (seem my analysis). 2) Not fsyncing the files before closeing them. It is not the job of cp nor scp to guarantee that any file has reached the disk. So this bug will not be fixed. If it was their job, tools like sync(1) would not exist in the first place. If it was, you could file this bug report against every single package handling files in the archive (except for a handful). Since that would be insane, I simply dropped this request in my previous reply. I should have made this more explicit. Can we now ignore 2) and concentrate on 1)? No. If I wanted this semantics I could use shred(1). I want my files saved. Note that this same issue has been found and fixed in dpkg. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hi Michal, On Mon, Dec 05, 2011 at 05:03:25PM +0100, Michal Suchanek wrote: Excerpts from Helmut Grohne's message of Mon Dec 05 15:54:19 +0100 2011: Can we now ignore 2) and concentrate on 1)? No. If I wanted this semantics I could use shred(1). Please report a separate bug about not using fsync then. (or clone this bug) They can be fixed independently. I want my files saved. Honestly. You seem to have a rather different view on this issue than the rest of the world (otherwise it would have been reported way earlier). As for me I really do *not* want fsync here. For instance when I use a slow usb storage device, I really want cp to finish before the copied stuff is written to permanent storage. So even I would assume that the fsync issue is just wontfix (even though I am not the openssh maintainer). Note that this same issue has been found and fixed in dpkg. This is good and all. But in general tools simply do not provide fsync semantics and people actually expect that now. When firefox tried to introduce fsync, it was disabled for performance reasons again. If you need it, go sync after you copy. (Or write patches.) Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Excerpts from Helmut Grohne's message of Mon Dec 05 18:15:53 +0100 2011: Hi Michal, On Mon, Dec 05, 2011 at 05:03:25PM +0100, Michal Suchanek wrote: Excerpts from Helmut Grohne's message of Mon Dec 05 15:54:19 +0100 2011: Can we now ignore 2) and concentrate on 1)? No. If I wanted this semantics I could use shred(1). Please report a separate bug about not using fsync then. (or clone this bug) They can be fixed independently. I want my files saved. Honestly. You seem to have a rather different view on this issue than the rest of the world (otherwise it would have been reported way earlier). I would guess that most of the rest of the world is not aware of this issue. It's probably not been like that since day 1 of Linux. I suspect that at some point Linux implemented some optimization that allows close() to finish before the space for the written data is even allocated and others like that which leads to these issues. As for me I really do *not* want fsync here. For instance when I use a slow usb storage device, I really want cp to finish before the copied stuff is written to permanent storage. Why? Either you want the data on the storage so you eject it and wait for eject to finish anyway or you are doing something else in the meantime so you can do so regardless of cp finishing or not. So even I would assume that the fsync issue is just wontfix (even though I am not the openssh maintainer). Note that this same issue has been found and fixed in dpkg. This is good and all. But in general tools simply do not provide fsync semantics and people actually expect that now. When firefox tried to introduce fsync, it was disabled for performance reasons again. If you need it, go sync after you copy. (Or write patches.) No, it is not good at all that fsync is not used in things like cp. It was not used in dpkg which led to severe system corruption which is now fixed but any other tools used to manipulate files should do the same. Otherwise they are useless. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
On Mon, Dec 5, 2011 at 19:57:59 +0100, Michal Suchanek wrote: I would guess that most of the rest of the world is not aware of this issue. Please kindly take me off your nonsense rants. And better yet, take them off the debian bug tracking system. TIA, Julien -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Excerpts from Helmut Grohne's message of Sat Dec 03 17:33:04 +0100 2011: Hi, On Sun, Jan 02, 2011 at 03:48:05PM +0100, Michal Suchanek wrote: This same issue also happens with cp(1) from coreutils. I verified that this statement is wrong. It is not. 1) The coreutils actually check the return value of close which can be seen on copy.c. It has precisely two calls to close and both are checked. 2) I created a simple LD_PRELOAD library to make close fail (attached). Running cp foo bar with this library preloaded (i.e. failing any close with EIO) I get the following output and return value 1: cp: closing `foo': Input/output error This is correct behaviour. Since scp invokes cp for local copies, the test originally submitted testcase Michal Suchanek wrote earlier: $ scp /scratch/junk . ; echo $? 0 $ rm junk is wrong as well. This command would output a similar error message to the one above. However this does not invalidate the bug immediately. To be sure, remote transfers need to be checked as well. Please read the analysis in the latter message. A quick grep of the openssh source indicates that checking close is overrated. Who needs errors anyway? I want that it works!!1!eleven And for it to work it needs to report errors when they happen. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hi,
On Sun, Jan 02, 2011 at 03:48:05PM +0100, Michal Suchanek wrote:
This same issue also happens with cp(1) from coreutils.
I verified that this statement is wrong.
1) The coreutils actually check the return value of close which can be
seen on copy.c. It has precisely two calls to close and both are
checked.
2) I created a simple LD_PRELOAD library to make close fail (attached).
Running cp foo bar with this library preloaded (i.e. failing any close
with EIO) I get the following output and return value 1:
cp: closing `foo': Input/output error
This is correct behaviour. Since scp invokes cp for local copies, the
test originally submitted testcase
Michal Suchanek wrote earlier:
$ scp /scratch/junk . ; echo $?
0
$ rm junk
is wrong as well. This command would output a similar error message to
the one above. However this does not invalidate the bug immediately. To
be sure, remote transfers need to be checked as well.
A quick grep of the openssh source indicates that checking close is
overrated. Who needs errors anyway? I want that it works!!1!eleven
Helmut
CFLAGS ?= -Wall -Wextra -W -pedantic -fPIC -rdynamic
LIBS=-lc -ldl
%.o:%.c
${CC} ${CFLAGS} -c $ -o $@
closefail.so:closefail.o
${CC} ${CFLAGS} -shared -o $@ $^ ${LIBS}
closefail.o:closefail.c
#include unistd.h
#include errno.h
#include string.h
#include stdlib.h
int close(int fd) {
/* just leak the fd */
static int failcount=0;
if(failcount == 0) {
const char *p;
p = getenv(CLOSEFAIL);
if(p != NULL)
failcount = atoi(p);
}
failcount -= 1;
if(failcount == 1) {
errno = EIO;
return -1;
}
if(failcount 1)
failcount = 1;
return 0;
}
Bug#607267: /usr/bin/scp: fails to notice close() errors
Hello Excerpts from Julien Cristau's message of Sat Dec 25 22:00:11 +0100 2010: user release.debian@packages.debian.org usertag 607267 squeeze-can-defer tag 607267 squeeze-ignore kthxbye On Thu, Dec 16, 2010 at 13:40:30 +0100, Michal Suchanek wrote: Package: openssh-client Version: 1:5.5p1-5+b1 Severity: grave File: /usr/bin/scp Justification: causes non-serious data loss scp fails to notice close() errors. I'm not sure this is grave, but in any case this won't block the release, tagging accordingly. As data loss is defined as grave I would expect this is the case. I tried on 2.6.36 release kernel (not rc) and the issue stays. I also tried to open and write a file in a scripting shell and found that the error is only reported on fsync(). Not sure if this is compliant to anything but the Linux close(2) man page clearly states: A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a file system to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.) This suggests that the reason the error is not recognized is due to scp not doing fsync() which is the only guaranteed way to ensure that the data is ever written to the file. This condition may occur when you run out of disk space (which is hopefully rare but the more surprising) and possibly when you run out of disk quota. This same issue also happens with cp(1) from coreutils. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
user release.debian@packages.debian.org usertag 607267 squeeze-can-defer tag 607267 squeeze-ignore kthxbye On Thu, Dec 16, 2010 at 13:40:30 +0100, Michal Suchanek wrote: Package: openssh-client Version: 1:5.5p1-5+b1 Severity: grave File: /usr/bin/scp Justification: causes non-serious data loss scp fails to notice close() errors. I'm not sure this is grave, but in any case this won't block the release, tagging accordingly. Cheers, Julien signature.asc Description: Digital signature
Processed: Re: Bug#607267: /usr/bin/scp: fails to notice close() errors
Processing commands for cont...@bugs.debian.org: user release.debian@packages.debian.org Setting user to release.debian@packages.debian.org (was jcris...@debian.org). usertag 607267 squeeze-can-defer Bug#607267: /usr/bin/scp: fails to notice close() errors There were no usertags set. Usertags are now: squeeze-can-defer. tag 607267 squeeze-ignore Bug #607267 [openssh-client] /usr/bin/scp: fails to notice close() errors Added tag(s) squeeze-ignore. kthxbye Stopping processing here. Please contact me if you need assistance. -- 607267: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607267 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607267: /usr/bin/scp: fails to notice close() errors
Package: openssh-client Version: 1:5.5p1-5+b1 Severity: grave File: /usr/bin/scp Justification: causes non-serious data loss scp fails to notice close() errors. To reproduce: - mount a 10M tmpfs - export it through samba - mount the share through cifs - take a 12M file (eg dd from /dev/zero) When you copy the file to the samba share no error is reported. The tail of the file is silently lost. $ scp /scratch/junk . ; echo $? 0 $ rm junk $ cat /scratch/junk | gzip -c junk gzip: stdout: No space left on device $ rm junk $ cat /scratch/junk | gzip -c | split -d -a 3 -b 6M - junk.gz. ; echo $? split: junk.gz.001: No space left on device 1 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (910, 'testing'), (900, 'stable'), (500, 'unstable'), (200, 'experimental'), (111, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.36-rc6-r600fence-smbinit-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openssh-client depends on: ii adduser 3.112+nmu2 add and remove users and groups ii debconf [debconf-2.0 1.5.36 Debian configuration management sy ii dpkg 1.15.8.5Debian package management system ii libc62.11.2-7Embedded GNU C Library: Shared lib ii libedit2 2.11-20080614-2 BSD editline and history libraries ii libgssapi-krb5-2 1.8.3+dfsg-3MIT Kerberos runtime libraries - k ii libssl0.9.8 0.9.8o-3SSL shared libraries ii passwd 1:4.1.4.2+svn3283-2 change and administer password and ii zlib1g 1:1.2.3.4.dfsg-3compression library - runtime Versions of packages openssh-client recommends: ii openssh-blacklist 0.4.1 list of default blacklisted OpenSS ii openssh-blacklist-extra 0.4.1 list of non-default blacklisted Op ii xauth 1:1.0.4-1 X authentication utility Versions of packages openssh-client suggests: pn keychain none (no description available) pn libpam-sshnone (no description available) pn ssh-askpass none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
