Red Hat Bugzilla – Bug 22045
gzip-1.3 compresses and follows symlinks!
Last modified: 2005-10-31 17:00:50 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 @@
PROGRAMS = $(bin_PROGRAMS)
-DEFS = @DEFS@ -I. -I$(srcdir) -I.
+DEFS = @DEFS@ -DHAVE_LSTAT -I. -I$(srcdir) -I.
CPPFLAGS = @CPPFLAGS@
LDFLAGS = @LDFLAGS@
LIBS = @LIBS@
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."
In summary: PLEASE FIX THIS SOON, BEFORE ANYONE ELSE GETS HURT. :-)
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)