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:
> > >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.

>                                  I ask again: do you have a legitimate
> use case?  Is there _any_ case that other checks can succeed that this
> invented test of yours would catch?

I already explained what they are. You may think you can always use ptrace,  
but ptrace cannot be used in every case. Furthermore, even if ptrace can,  
somehow, be used, that does not invalidate the value of the check.

It's the same reason why the bind-chroot package exists (setting aside for  
the moment the completely irrelevant side issue that bind-chroot in F17  
never worked, because apparently nobody bothered to actually execute  
"systemctl start named-chroot.service" and see if "dig www.yahoo.com" works  
afterwards, after fscking around with its systemd.unit file, or even read  
the months-old bugzilla report documenting the breakage, and what needs to  
be done to fix it). Putting bind in a chroot jail offers no apparent benefit  
or value, according to this same kind of logic. Yet, clearly it has value,  
even though it's impossible for some to see it.

-------------- 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/20120717/a60649ca/attachment.sig>