Bug 22045 - gzip-1.3 compresses and follows symlinks!
gzip-1.3 compresses and follows symlinks!
Product: Red Hat Linux
Classification: Retired
Component: gzip (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2000-12-10 20:59 EST by Jeff Norden
Modified: 2005-10-31 17:00 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-12-10 20:59:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Norden 2000-12-10 20:59:15 EST
It's nice to have the new gzip in RedHat-7.0, but the version as supplied
is badly broken, and actually rather dangerous!

The problem is that gzip-1.3 is compiled *without* setting the HAVE_LSTAT
pre-processor flag which now appears in gzip.c.  The result is that instead
of ignoring symbolic links (as the gzip man page still claims), gzip is
completely unaware of symbolic links!  I've attached my own personal
"horror story" below to illustrate just how bad this behavior can be.

The *correct* fix is probably to update the configure/automake setup (or
maybe just eliminate HAVE_LSTAT).  But that is perhaps best left to the Gnu
maintainer(s) when/if gzip-1.3.x is "officially" released.  For now, it is
probably easiest to just patch the Makefile.  Here is a simple fix that
works form me:

--- Makefile.in.save	Tue Dec 21 00:59:39 1999
+++ Makefile.in	Thu Dec  7 23:53:59 2000
@@ -108,7 +108,7 @@
-DEFS = @DEFS@ -I. -I$(srcdir) -I.
+DEFS = @DEFS@ -DHAVE_LSTAT -I. -I$(srcdir) -I.

Begin "Horror Story."

Without the above fix, when gzip is applied to a symlink to a plain file it
will replace the symlink with a gziped version of the referenced file, but
will not delete or change the referenced file.  This is odd behavior,
perhaps, but not disastrous.

The more serious problem is that 'gzip --recursive' will follow symbolic
links to directories, which can lead to far more gzipping than intended! 
This, unfortunately, is how I discovered the bug.

I recently replaced an aging sparcstation with a new linux-i386 box.  Using
tar, I transfered the entire directory structure from the old machine into
a directory on the new machine.  I then moved most of the relevant local
and user files to appropriate locations on the new machine.  I wasn't quite
ready to delete the remaining stuff yet, but I wanted to reclaim some of
the space.  I started 'gzip --recursive' on the directory containing the
old files, and went home.  (Since I had preserved the file ownerships, I
had to run gzip as root.)  Most of the absolute symlinks (i.e., those
starting with a /) within the old structure were now invalid, and relative
symlinks just pointed to other old files.  But there was an absolute
symlink to '/usr/lib/X11'.  Furthermore, within the subdirectories of
/usr/lib/X11 there are several symlinks to subdirectories of /etc/X11/. 
So, when I returned the next day, my X11 setup was quite broken.  I'm
actually quite lucky that gzip didn't hit an absolute link to /etc or /home
or (gasp) /.  It would have taken quite a bit longer to recover from that!

End "Horror Story."


Comment 1 Trond Eivind Glomsrxd 2000-12-10 21:59:48 EST
Fixed in gzip-1.3-10, coming soon to a Rawhide mirror near you. Thanks for
report and fix (I used CPPFLAGS instead of patching, but used the same flag)

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