Description of problem:
When tar is started with STDOUT closed, it fails to unpack the gzipped archive,
because of a bug in tar.

Version-Release number of selected component (if applicable):
tar-1.15.1-24.fc6

How reproducible:
100%

Steps to Reproduce:
1. create a gzipped tar archive, named "file.tar.gz"
2. run "tar xf" with stdout closed ("tar xf file.tar.gz >&-" in bash syntax)
  
Actual results:
gzip: stdout: Bad file descriptor
tar: Child returned status 1
tar: Error in writing to standard output
tar: Error is not recoverable: exiting now


Expected results:
tar archive should be correctly unpacked regardless of file descriptor setup

Additional info:
I have found this problem when running tar from mod_perl script under Apache2 -
Apache does not keep the file descriptors 0, 1, and 2 set up for its children.
So external commands may occasionally run with stdout or stdin closed.

running "strace -f -o /tmp/strace.out -- tar xf file.tar.gz" revealed what tar
does when spawning the "gzip -d" child:

- after fork(), the tar child process has "file.tar.gz" opened as filedescriptor
#1, and the output side of the pipe to its parent as filedescriptor #3. Before
exec()ing "gzip -d", the child does the following:

// switch the pipe to fd #1:
close(1); // oops, we have lost our compressed input file :-(
dup(3); // duplicates the write side of the pipe to fd#1
close(3); // get rid of the old pipe descriptor
// now switch the input stream to fd #0 (but at this point, we
// don't have the compressed file opened anymore)
close(0);
dup(1); // but it duplicates the write side of the pipe instead
close(1);
// after we exec "gzip -dc", it does not have fd #1 opened

I suggest that tar should explicitly check whether it has filedescriptors 0 and
1 opened, and also that it use dup2() instead of dup().