Bug 113992

Description of problem:

I spent 4 hours today trying to find the "hacker" who had replaced all
the binaries in /bin and /usr/bin, changing the ctime, size, and
md5sum but not the mtime.  It turned out to be prelink.  I had never
heard of prelink so it took a *long* time to figure out what had happened.

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

prelink-0.3.0-13

How reproducible:

always

Steps to Reproduce:
1. update glibc
2. wait a day
3. ls -lctr /bin
  
Actual results:

ctimes change on all your binaries, leading you to think a hack has
happened

Expected results:

ctimes and mtimes change, and you are well-enough educated by the
release notes to know why.

Additional info:

This is a feature request.  Prelink's regular activity looks like
someone has hacked your system, particularly if, as in my case, the ls
program crashed (probably for unrelated causes) and you are looking
for hacks, which often replace binaries with hacked versions that have
 mtimes unchanged but sometimes have ctimes changed.  Here's what
would have been better:

First, DOCUMENT prelink in the release notes and announcements for a
while.  I'd recommend putting something out on the mailing list about
it right now, since FC1's first glibc update was not long ago.

Second, why does prelink not change the mtime?  It's changed the
contents of the file, so the mtime should change.  Apparently, you
have already hacked rpm -V to do checksums on the non-linkage part of
the binary, so it's not outrageous for the prelink script to call rpm
with some option to update the time of the file in the rpm database
(so rpm -V is still quiet).

Third, have prelink log its activity in /var/log/prelink, so those
looking for hackers will find activity in the logs at the time of the
supposed hack, and know what happened.

--jh--