Bug 115047 - rpm -Va on freshly installed machine shows multiple modified binaries
rpm -Va on freshly installed machine shows multiple modified binaries
Status: CLOSED RAWHIDE
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: distribution (Show other bugs)
3.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
:
Depends On:
Blocks: 108098 123574 IT#42221
  Show dependency treegraph
 
Reported: 2004-02-05 16:16 EST by Chris Kloiber
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-06 23:40:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
list of modified binaries. (2.44 KB, text/plain)
2004-02-05 16:16 EST, Chris Kloiber
no flags Details
With linefeeds and sorted for readability (27.30 KB, text/plain)
2004-02-10 15:26 EST, Chris Kloiber
no flags Details
Also sorted for readability (81.35 KB, text/plain)
2004-02-10 15:27 EST, Chris Kloiber
no flags Details

  None (edit)
Description Chris Kloiber 2004-02-05 16:16:01 EST
Description of problem:

If you do an "Custom/Everything" install on any x86_64 machine, then
immediately run 'rpm -Va' to check for modified files, a large number
of binary files appear to be modified. (attached list to follow)

There should *never* be modified binaries in rpm -Va output, but
especially not immediately after installaiton, when no modifications
have been made to the system yet. Support uses 'rpm -Va | grep bin' as
one quick check to see if a system may have been hacked.

My theory is packaging problems with biarch packages (where both x86
and x86_64 versions aof a package exist and overlap)
Comment 1 Chris Kloiber 2004-02-05 16:16:55 EST
Created attachment 97501 [details]
list of modified binaries.
Comment 3 Jeff Johnson 2004-02-10 13:45:56 EST
Can you attach rpm -qa --qf '%{name}%{version}-%{release}.%{arch}'
output so's I can see what's what?

rpm -qa --last prolly helpful as well.

Tnx.
Comment 4 Chris Kloiber 2004-02-10 15:26:56 EST
Created attachment 97563 [details]
With linefeeds and sorted for readability
Comment 5 Chris Kloiber 2004-02-10 15:27:33 EST
Created attachment 97564 [details]
Also sorted for readability
Comment 6 Alexandre Oliva 2004-07-30 10:48:05 EDT
I don't think this should be in NEEDINFO.  Changing to ASSIGNED.
Comment 7 Jeff Johnson 2004-07-30 14:07:15 EDT
While I understand the expectation that "No output is AOK"
from rpm -Va, the files -- in fact -- have been changed
by installing both ix86 and x86_64 binaries.

Changing the output of rpm -Va to conform to expectations
has deep security implications for all users, and any
change to rpm -Va behavior to accomodate "No output is AOK"
would then violate other expectations.

I prefer leaving the existing and traditional behavior
which reports (expectationally) false positives rather than
changing -Va to pretend that files have not changed (when
they have) by implementing false negative output.

Sure additional options could have it both ways. The issue
then becomes what is the default, which, of necessity, is
exactly what is currently happening.

WONTFIX is my call, the final call is not mine.
Comment 8 Alexandre Oliva 2004-08-18 13:22:55 EDT
But what happens if I remove the 64-bit package, leaving the 32-bit
package installed?  Don't I end up without the 32-bit binary that
should have remained there?

I really think the notion of silently overwriting binaries is a
misguided one, unless rpm were to save the 32-bit files somewhere it
could restore them later.  And if it does save them, it might as well
check those files instead, and you won't get any false positives.
Comment 15 Jeff Johnson 2004-10-06 23:40:07 EDT
This should be implemented in latest rpm-4.3.2.

Note that you will need install with the latest rpm-4.3.2,
as the change was to mark replaced files in the database,
so either fresh install or pkg reinstall is needed to
change the marking.

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