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. :-) Thanks.
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)