prelink should not mess with running executables

[Sam Varshavchik]

Andrew Haley writes:

> On 07/19/2012 12:10 PM, Sam Varshavchik wrote:
> > Andrew Haley writes:
> >
> >> On 07/18/2012 11:37 PM, Sam Varshavchik wrote:
> >>>
> >>> How do you know that the server that gave you a seemingly verified SSL
> >>> certificate, that checks out, isn't an impostor that managed to crack the
> >>> right prime.
> >>
> >> Because we know that to do that is at the present, time
> >> computationally intractable.  So, it's very unlikely that it's
> >> happened unless your opponent is prepared to spend huge resources on
> >> you.
> >
> > But it's not impossible.
>
> No, and neither is it impossible that your computer will turn into a
> bowl of petunias.

Right. And that makes the argument against using the binary's pathname for  
authentication-related purposes, because there are marginal race condition  
where it doesn't work, equally bogus, for pretty much the same reasons.

Glad we at least agree on this point.

> > Same thing here. It is "very unlikely" that /proc/pid/exe gives you
> > the pathname that was used to start the executable.  But just
> > because there are marginal situations where it might not work does
> > not invalidate its value-added benefits.
> >
> >>> If what prelink is doing is hunky-dory, then why is it that its
> >>> wrapper has special-case band-aid init?
> >>
> >> What's a special-case band-aid about it?  It looks perfectly
> >> reasonable to me.  Why wouldn't you restart init?
> >
> > Why would you?  If there's nothing wrong with with overwriting an
> > executable, and, after all, that's how UNIX worked forever, then why
> > bother restarting init?
>
> Hmm, isn't this to make sure that init is using the current libraries
> and not holding open the old ones forever?  Sounds perfectly
> reasonable to me.

I don't know the exact reason, but the exact reason is not the point, the  
point is that there is some reason to do that, because overwriting the  
executable has negative impact. That might be one of them. Invalidating  
/proc/self/exe is another one.

We've just established that what prelink is doing is harmful.

> >> But this is nothing to do with prelink.  It's to do with your totally
> >> bogus assumption that /proc/self/exe is a reliable way to get the
> >> binary image of the executable that started current process.  It
> >
> > Well, that's only what proc(5) says it is.
>
> Maybe we can fix the man page then.
>
> > And it works every time. Until prelink overwrites the executable.
>
> But that's just the point: until something overwrites the executable.

Not exactly. The point is, unless I'm not aware of something, prelink is the  
only cause which is random, unpredictable, and cannot be controlled. For all  
other situations, you have some way of having a controlled, orderly process.  
For upgrades, for example, you can take care of whatever needs to be done  
using the hooks. But I'm unable to see anything comparable for prelinks  
daily attacks on the filesystem.

> >> isn't, it never has been, and it never will be.  And this is true
> >
> > If the contents of the /proc/self/exe symlink are something random
> > and unrelated, then I think that proc(5) needs to be updated to
> > reflect that.
>
> Perhaps so.  At best it's only the path to the executable that started
> the program.

Which works for me just fine.

> >> not just because of prelink; even without prelink you'll still have
> >> to be able to cope with this situation.
> >>
> >> The basic principle of robust programming is that you must expect the
> >> unlikely and treat it as normal.  This is a classic case of that
> >> principle.
> >
> > No, this is a classic case of denying the problem's root cause,
>
> The root cause is the filesystem behaviour of UNIX that allows a
> program to continue even though its executable file has been
> rewritten.  That's a feature, not a bug, and it's what allows updating
> to be done without restarting.

No, the root cause is that prelink does it in an uncontrolled, haphazard  
fashion, with no means of mitigating the results, other than adding more  
individual hacks into its wrapper.

> > and blaming something else, which exposes the problem.
>
> You have a clear choice.  You can either write a robust program that
> can continue to run in the presence of prelink, updates, and anything

I'm already handling updates. Updates are a no-brainer. It's a controlled,  
orderly process, and I can handle my housekeeping using the hook scripts.

There is nothing comparable that can be used with prelink.

Lumping prelink's fallout together with upgrades, or "anything" (whatever  
that is) is absurd.

-------------- 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/20120719/dd4e2266/attachment.sig>