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--
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 in /var/log/prelink.log. 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. --jh--