Chris Adams writes:
Once upon a time, Sam Varshavchik <mrsam(a)courier-mta.com>
> 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
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
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
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
how do you
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
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.