prelink should not mess with running executables

[Chris Adams]

Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
> No, it's not because init is "not a standard daemon". prelink did not 
> single  out init for special treatment just because of its special status. 
> prelink  does this to every binary, not just init. It's just that the 
> results of  prelink's frak-up are critical in init's case.

??? prelink most certainly does NOT restart every daemon.  prelink
restarts init because historically init didn't always re-exec itself at
shutdown, which in turn caused the root filesystem to not be cleanly
unmounted.

> You are saying that the special-casing of init in prelink's wrapper is  
> justified because without it, what prelink ends up doing to init will 
> result  in a crash.

Nope, no crash.  Just an unclean filesystem shutdown due to the one and
only long-running process still active at that point.  Back in the days
before journalling filesystems, that could cause an unwanted fsck.

> Until someone explains how exec($pathname) results in two completely  
> different binaries getting started (excepting prelink's brain damage, and,  

As I already said, chroot() can cause this as well.  Since there are a
number of FTP servers that utilize chroot() to limit file uploads to a
subdirectory, a bug in one of them that allows a user to exec()
something breaks your pathname assumption.  That is many orders of
magnitude more likely than the credential passing you claim is
insufficient (thus requiring your invented pathname check) having a bug
(especially since such bugs have happened in FTP servers but no such
kernel bugs have happened).

> >                                                        how do you know
> >the binary hasn't been modified in place?  What good is your
> >super-special pathname security then?
> 
> You are again trying to change the topic.

No, you are dodging.  You are the sole person claiming prelink is
broken, and your sole reasoning is based on a faulty assumption.  I'm
merely pointing out other reasons your assumption is faulty.  prelink is
not broken as you claim.

> And because you have no answer to that (and because once someone has root  
> and can overwrite stuff in /usr/bin, all bets are off anyway, which you 
> also  ignore), you must then start attacking the dependency that brings it 
> out, as  a factor, instead of addressing it directly.

Well, once someone has root, they could load a kernel module that
changes the proc filesystem code to report whatever they want when
readlink() is done on /proc/<pid>/exe, or change the results of stat()
when checking a particular binary (I'm pretty sure there have been
rootkits that do the latter).

> But, because of the way that happens, it breaks daemons that rely on  
> comparing /proc/[pid]/exe, which I assert is a valid mechanism for making  
> that comparison.

It breaks _your_ daemon, because that's the only one that attempts to
rely on such a broken assumption.

> the  /proc/pid/exe symbolic link names the pathname of the binary 
> that the  process was started with.

And that doesn't change - /proc/pid/exe is the pathname.  However, the
inode that the pathname points at may have changed (or the pathname may
even have been deleted).  There has never been any guarantee otherwise.

This is my last message in this thread.
-- 
Chris Adams <cmadams at hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.