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

Bug#607267: /usr/bin/scp: fails to notice close() errors


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

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

CFLAGS ?= -Wall -Wextra -W -pedantic -fPIC -rdynamic 
LIBS=-lc -ldl
	${CC} ${CFLAGS} -c $< -o $@
	${CC} ${CFLAGS} -shared -o $@ $^ ${LIBS}
#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;

Reply to: