Bug 227523 - Unpacking compressed archive fails when STDOUT is closed
Unpacking compressed archive fails when STDOUT is closed
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: tar (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Lukas Vrabel
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-06 12:14 EST by Jan "Yenya" Kasprzak
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version: fc6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-04 08:41:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch is fixing this issue for tar 1.15.1 (4.00 KB, patch)
2007-02-09 10:41 EST, Lukas Vrabel
no flags Details | Diff

  None (edit)
Description Jan "Yenya" Kasprzak 2007-02-06 12:14:10 EST
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().
Comment 1 Lukas Vrabel 2007-02-08 08:24:59 EST
it's fixed in upstream 1.16.1
Comment 2 Jan "Yenya" Kasprzak 2007-02-08 08:29:19 EST
Thanks, will you issue a new package for FC6, or should I create my own
upstream-based package?
Comment 3 Jan "Yenya" Kasprzak 2007-02-08 08:38:42 EST
BTW, this bug is also in RHEL4 (tar-1.14-12.RHEL4).
Comment 4 Lukas Vrabel 2007-02-08 08:51:43 EST
for more info on 1.16.1 see bug no 226917: http://bugzilla.redhat.com/bugzilla/
show_bug.cgi?id=226917
Comment 5 Jan "Yenya" Kasprzak 2007-02-08 09:25:10 EST
http://people.redhat.com/pvrabec/rpms/tar-1.16.1-1.src.rpm
works for me (I had to install m4 and autoconf from -devel to compile it, though).
Comment 6 Lukas Vrabel 2007-02-09 10:41:29 EST
Created attachment 147781 [details]
patch is fixing this issue for tar 1.15.1

run automake after applying patch
Comment 7 Fedora Update System 2007-04-12 15:42:44 EDT
tar-1.15.1-25.fc6 has been pushed for fc6, which should resolve this issue.  If these problems are still present in this version, then please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.