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 188.8.131.52-127.fc12.i686.PAE #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
[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
......... d /usr/share/man/man1/ipcalc.1.gz
[root@gamma initscripts]# man rpm
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.
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.
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.
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
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).
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.
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?
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
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.
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:
/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.