Bug 613286 - rpm --verify initscripts ignores /bin/ipcalc in undocumented fashion
Summary: rpm --verify initscripts ignores /bin/ipcalc in undocumented fashion
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: 12
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-10 13:01 UTC by Edward J. Huff
Modified: 2010-11-03 12:38 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-03 12:38:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Edward J. Huff 2010-07-10 13:01:03 UTC
Description of problem:

The rpm man page does not warn us that files listed under %exclude or %config(missingok) in the spec file will be falsely reported as perfect match when in fact they differ from the version shipped in the .rpm file.  For example, /bin/ipcalc in initscripts.

Version-Release number of selected component (if applicable):
Linux gamma.localnet #1 SMP Fri May 28 04:47:04 UTC 2010 i686 i686 i386 GNU/Linux

How reproducible: perfectly.

Steps to Reproduce:
[root@gamma ~]# mkdir initscripts
[root@gamma ~]# cd initscripts/
[root@gamma initscripts]# yumdownloader initscripts
Loaded plugins: dellsysidplugin2, refresh-packagekit
initscripts-9.02.2-1.i686.rpm     | 931 kB     00:00     
[root@gamma initscripts]# rpm -q initscripts
[root@gamma initscripts]# rpm2cpio initscripts-9.02.2-1.i686.rpm | cpio --extract --make
11276 blocks
[root@gamma initscripts]# cmp bin/ipcalc /bin/ipcalc
bin/ipcalc /bin/ipcalc differ: byte 33, line 1
[root@gamma initscripts]# rpm --verify initscripts
..5....T.  c /etc/inittab
[root@gamma initscripts]# rpm --verify --verbose initscripts | grep ipcalc
.........    /bin/ipcalc
.........  d /usr/share/man/man1/ipcalc.1.gz
[root@gamma initscripts]# man rpm

Actual results:

The man page explains about exceptions for documentation files, configuration files, ghost files, license files, readme files, but does not mention any exception for %exclude files or %config(missingok) files.

       c %config configuration file.
       d %doc documentation file.
       g %ghost file (i.e. the file contents are not included in the package payload).
       l %license license file.
       r %readme readme file.

Expected results:

The man page should mention that there are also %exclude and %config(missingok) files which will not be compared but which will be reported as matching even if they do not match.

Alternatively, rpm should be fixed to add attribute markers for %exclude and %config(missingok) files in the verify report, and it should go ahead and do the comparison and report the results, as it does for configuration files, etc.  Of course, this still requires changes in the man page.

Additional info:

See also Bug 124514 - rpm verify misses "missing files/links"

The reporter failed to point out the missing documentation and it was closed as NOTABUG because rpm experts expected that behavior.  In that case, it was %config(missingok) in the spec file.

Considering those two undocumented (in the man page) exceptions, there might be others as well.

Comment 1 Jeff Johnson 2010-07-11 14:13:47 UTC
RPM --verify compares explicit file information from header metadata
with what is actually installed.

With %exclude there is no metadata to use for the comparison. In fact,
%exclude is a directive to indicate that a file should NOT be included
in a package whatsoever.

With %config(missingok) a comparison isn't possible because the
file on the filesystem isn't present. The %config(missingok) directive
is used to indicate to --verify that a file that isn't present is an
acceptable condition.

So its not clear what you are expecting from --verify with files
that aren't in a package and for files which are not present
(which is marked as an acceptable non-error condition).

Comment 2 Edward J. Huff 2010-07-13 08:03:32 UTC
Well, in the /bin/ipcalc case, the file is present in the rpm when unpacked using rpm2cpio ... | cpio --extract --make.  And the file is listed in the rpm -ql, and rpm -qf /bin/ipcalc says initscripts is the package which provided the file.

And, rpm --verify --verbose initscripts reports that /bin/ipcalc is an exact match for the payload in the rpm, even though it is not.

So, if rpm does not actually compare the file, then it should not say that it does.

And if the file comes from some other place, then rpm should not say it comes from initscripts.  By the way, where does it come from?

In the case of missingok, the output of verify should be different from the case of a file which is an exact match.  It should have a missingok attribute letter, and the difference columns should show failure to match.

Or in the alternative, the man page should include the information in comment number two, warning us that the --verify output is not to be taken literally in all cases, and telling us how to extract the spec file from the SRPM in order to find out if this is the case.

Comment 3 Edward J. Huff 2010-07-13 08:07:23 UTC
How am I supposed to know whether or not /bin/ipcalc has been modified by a rootkit?  (Assuming of course that the rpm database is hosted in a secure location... and rpm itself is secure, as in a rescue disk?)

What good is rpm --verify if it lies?

Comment 4 Jeff Johnson 2010-07-13 12:12:00 UTC
My comments were addressed generally to an RFE to add %exclude
or %config(missingok) to --verify.

Examine the /bin/ipcalc file install state (using -qs) and the
file verify flags. rpm (like any program) doesn't randomly
claim that a file is part of package when it isn't, nore does
it flip a coin to decide what comparison operations to perform
with --verify.

How do you know that /bin/rpm hasn't been altered by a rootkit,
and displaying wrong information?

The answer for rootkit forensics is beyond the scope of a rpm bug report,
but may include extracting the file digest and comparing with
the digest computed from the installed content, or comparing with the
original packaging, or examining the install state and file verify flags
and other install state (like verifyflag disablers) associated with a file.

But if you believe "rpm --verify" lies to you, do not use it. Its your
system, and your security, and your decision, not anything else.

Comment 5 Bug Zapper 2010-11-03 12:07:52 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 6 Panu Matilainen 2010-11-03 12:38:33 UTC
/bin/ipcalc is %config(missingok) or %exclude'd but a regular ELF binary, and the difference comes from our good friend prelink mixing things up. Rpm undoes prelinking when verifying so it doesn't show up as modified, 'cmp' only looks at the raw data as its on disk. No bug here.

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