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):
Steps to Reproduce:
1. update glibc
2. wait a day
3. ls -lctr /bin
ctimes change on all your binaries, leading you to think a hack has
ctimes and mtimes change, and you are well-enough educated by the
release notes to know why.
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.
prelink is documented in release notes and has been mailed about
on the mailing list many times.
mtimes is not changed on purpose and prelink logs its activity
What else are you missing?
The mailing list I was referring to was fedora-announce-list, where it
hadn't been mentioned. Something in fedoranews.org would help, too.
Not changing mtimes breaks ancient unix standards. The contents of
the file have changed, therefore so should the mtime. If you end up
with a file of the same size, rsync won't back it up, for example, and
as I mentioned the current activity looks like (and therefore masks)
common hacking activity.