Bug 128637 - texinfo: install-info & bz2 files
texinfo: install-info & bz2 files
Product: Fedora
Classification: Fedora
Component: texinfo (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
Ben Levenson
Depends On:
  Show dependency treegraph
Reported: 2004-07-27 12:36 EDT by Steve Grubb
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 4.8-9
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-16 00:22:12 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch currently being tested (1.48 KB, patch)
2004-07-29 12:34 EDT, Steve Grubb
no flags Details | Diff

  None (edit)
Description Steve Grubb 2004-07-27 12:36:33 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4.2)

Description of problem:
I was investigating some strange actions of install-info and started a
code review.

readfile calls open_possibly_compressed_file(). That function tries
opening the file with a number of different file extentions.
Eventually, it tries fopening a bz2 file. If that is successful, it
returns the FILE pointer, not a gzfile pointer.

readfile, then passes that descriptor to gzRead. I doubt that gzRead
can make heads or tails of a bzip2 compressed file. The problem is
that the zlib patch does not handle the possibility of bzip2 files.

There are 3 options as I see it:

1) remove the zlib patch. If this is done, full pathnames should be
used for the decompressors. Other security measures should be taken as

2) Delete the fopen of the bzip2 file. In this way, only uncompressed
text or gzip'ed files will successfully open.

3) Add bz2 support. This involves using a void pointer to
open_possibly_compressed_file(), using a flag to branch to bzRead
instead of gzread, using bzReadOpen, adding -lbz2 to flags, adjusting
configure to locate it, and a new BuildRequires.

I suspect a malicious person could create bz2 files knowing that
install-info may crash on them.

Version-Release number of selected component (if applicable):

How reproducible:
Didn't try

Steps to Reproduce:
1. Found in code inspection

Additional info:
Comment 1 Steve Grubb 2004-07-29 12:34:43 EDT
Created attachment 102287 [details]
patch currently being tested
Comment 2 Steve Grubb 2004-07-29 12:38:17 EDT
In case you are considering option #1, I have attached a patch that
uses full pathnames to the compressor/decompressors. Additionally,
gunzip can handle .Z uncompress files. So gunzip was substituted for

I am currently testing in this mode and do not see anymore problems
with install-info. I commented out the zlib patch at line 51 of the
spec file and added the attached patch.

Even if you may disagree with this approach, it is wiser to use full
paths for the info utility helpers. The man utility uses full paths,
so should info.
Comment 3 Tim Waugh 2004-07-29 13:25:34 EDT
I think they way forward is to fix the patch.  Is this actually
causing problems right now?  We don't ship any .bz2 info files as far
as I can see.
Comment 4 Steve Grubb 2004-07-29 14:34:34 EDT
It may be true that you do not ship bz2 info files, but that does not
precude others from doing it. Info files that are bzip2'd are smaller.
For example, tar.info.bz2 is 90007 while tar.info.gz is 115960. It
really does add up when you have hundreds of them.

If you do not like ripping out the zlib code, please use the fullpath
part for the info utility. I think it was the first hunk of the patch.
It might even be better to turn filesys.c into filesys.c.in and use
configure/autoconf to insert the full path like 'man' does.

Comment 5 Miloslav Trmač 2006-01-16 00:22:12 EST
I have changed the zlib patch to restore popen () use;
gzipped files are handled with zlib, bzip2ed by piping from bzip2.

Thanks for your report.

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