prelink should not mess with running executables

[Sam Varshavchik]

Chris Adams writes:

> Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
> > Chris Adams writes:
> > >Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
> > >> Chris Adams writes:
> > >> >Is there any value in this "additional check" (that nobody else
> > >> >apparently does)?  Do you not trust the kernel's credential handling?
> > >>
> > >> I certainly trust it. But just because I trust it, it doesn't mean that
> > >any
> > >> additional checks have no value.
> > >
> > >Sure it does.  If the credentials are always correct, additional checks
> > >past that are a waste of cycles.
> >
> > You feel absolutely confident that just because you can't think of any
> > value  of additional checks, there cannot possibly be any.
> >
> > You're wrong.
>
> Prove it.

Why? I am not trying to prove this. I am trying to prove that prelink is  
broken. The two are not the same.

Whether it does work, or does not work, that can stand on its own merits,  
and has no relevance on the merits of prelink's behavior of rewriting  
executables, without any means available of reliably remediating that, short  
of recording the same hack for every application that  
/etc/cron.daily/prelink does for /sbin/telinit.

If what prelink is doing is perfectly fine, then there's no reason to have  
the /sbin/telinit hack in /etc/cron.daily, is it? That statement, of course,  
would be either true or false irrespective of what I'm doing, which is  
completely irrelevant.

But, of course, nobody is willing to address that point.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120718/6826670f/attachment.sig>