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.
Attachment:
pgpNcuLzpoBPq.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
