prelink should not mess with running executables

[Sam Varshavchik]

Chris Adams writes:

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

There was no need to reexec init until prelink came along.

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

Whatever. Doesn't matter. The point is that prelink has to do it, in order  
to avoid the fallout.

If prelink's behavior did not have any damaging effects, there would be no  
reason to do that. Which, of course, is my point, which you are doing your  
best to avoid.

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

And as I already said, chroot requires root privileges. And if someone has  
root on your box, all bets are off.

That, of course, is a completely specious argument. Which I pointed out  
before.

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

No, I'm not the sole person. Whoever wrote that wrapper for prelink, for  
init, also claims that.

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

Right. And if someone has root, they can do a chroot jail too.

Your argument against the value in checking /proc/pid/exe essentially boils  
down, here, to the fact that root can defeat it.

That, of course, is an intellectually bankrupt proposition.

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

It's not broken, until prelink decides to rewrite every binary in the  
system, in an uncontrolled fashion. That's what broken, I'm just pointing it  
out. 

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

Not any more.

That's the point.

And you know it. You just don't have the courage to face the truth.


-------------- 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/20120720/75ee2f1c/attachment.sig>