Bug 113992 - prelink activity looks like a hack has happened: document better
Summary: prelink activity looks like a hack has happened: document better
Alias: None
Product: Fedora
Classification: Fedora
Component: prelink   
(Show other bugs)
Version: 1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-20 23:45 UTC by Joe Harrington
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-10-07 15:17:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joe Harrington 2004-01-20 23:45:16 UTC
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):


How reproducible:


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

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.


Comment 1 Jakub Jelinek 2004-01-21 22:45:13 UTC
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?

Comment 2 Joe Harrington 2004-02-27 19:22:16 UTC
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.


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