prelink should not mess with running executables

[Sam Varshavchik]

Chris Adams writes:

> Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
> > 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.
>
> As others have pointed out, that's because init is NOT a standard daemon
> (if you don't understand why PID 1 is special, I can't help you).

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.

The argument that prelink can only be an issue to daemons that continue to  
run past the shutdown system state is, of course, a specious argument. Just  
because other daemons get impacted by prelink's frak-up at other times,  
other than the system shut down, does not make the frak-up magically  
disappear with no side-effects, unfortunately.

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. But, since there's no crash with anyone else, even though  
prelink does the exact same thing, that makes it ok.

Which is, of course, an intellectually-bankrupt position to take.

Either what prelink is doing is damaging and/or improper, or it's not. If  
what it does is hunky-dory, and has no ill effects, then there would be no  
need whatsoever for any special hacks, for any special executables, not- 
withstanding some other "standard" or "special" status they have.

> You seem to be putting a lot of weight on the executable somebody ran to
> access your program, over and above all the kernel facilities for
> handling that (that are sufficient for everybody else, including heavily

The only facilities that I'm aware of, and have been mentioned here, is  
inotify. I already said that I find the notion of having to inotify  
yourself, in order to mitigate prelink's bull-in-the-china shop behavior –  
and only prelink's – to be utterly preposterous.

If inotify's the way to go here, then let's remove prelink's hack for init,  
and patch init to inotify itself, then. Sounds good to you?

The inotify proposition reminds of Dan Bernstein's famous suggestion for  
distributing the officially blessed, binary-only qmail builds that have  
compiled-in userids, in a userid-independent way: if you want to distribute  
the officially blessed qmail build without a dependency on particular  
numeric uid values of qmail's reserved usernames, just provide a post- 
install hook that patches qmail's binaries with the uids in use on that  
particular server.

Up to now, I never thought I'd ever come across another proposition that's  
just as mind-bending as that one.

Well, looks like I was wrong.

> security-minded folk like OpenBSD devs).  Aside from how a pathname is
> not really a good indicator (see SELinux vs. AppArmor),

Until someone explains how exec($pathname) results in two completely  
different binaries getting started (excepting prelink's brain damage, and,  
again, excluding other events that replace the binary, but which have easy  
ways to control, and mitigate), it looks like a pretty good indicator to me;  
except for, again, the breakage that results from prelink's unsolicited  
buggering.

>                                                         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. How good or not good it is, this  
has no merits on prelink's behavior, and the fact that there's no way –  
aside from silly hacks involving inotify – to make prelink do what it does  
in a more organized, well-behaved, civilized fashion.

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.

There may or may not be an argument about the merits of using a pathname for  
authentication. This is fine, and that subject can be debated elsewhere.  
But, now you have a situation where prelink's design results in a binary  
whose raw content is different, but it's, for all practical purposes, is the  
same binary.

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. Now, that's not the end of the world, of course, and I  
found a very obvious way to work around it (without doing stupid things with  
inotify) a while ago, but just thought that it was worthwhile to discuss if  
what prelink is doing can be improved.

But, apparently, this is impossible. Since it's not possible, apparently, to  
discuss prelink's flaws, the only response is to pretend that the problem  
must be elsewhere. You may or may think much of the benefits of comparing  
symlinks, but it is valid for it's documented and described purpose: the  
/proc/pid/exe symbolic link names the pathname of the binary that the  
process was started with. That's what it is. Except that it no longer is, as  
a result of prelink, and there is no convenient way to cooperate with  
prelink, to make it work, short of doing silly things with inotify. The fact  
that the same consequences can occur from upgrades, or some other  
unspecified events, is irrelevant, because appropriate measures /can/ be  
easily put in place, to take the appropriate action when upgrading, and most  
likely for whatever those other mysterious reasons might be. But this is not  
easily doable with prelink, without resorting to unwarranted nonsense, like  
inotify or similar workarounds.

If someone's incapable of understanding this fundamental fact, I see nothing  
else that can be discussed that was not already covered in this thread.

-------------- 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/151dfa0e/attachment.sig>