Chris Adams writes:
Once upon a time, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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.
