Chris Adams writes:
Once upon a time, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> said: > 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. ??? prelink most certainly does NOT restart every daemon. prelink restarts init because historically init didn't always re-exec itself at shutdown, which in turn caused the root filesystem to not be cleanly unmounted.
There was no need to reexec init until prelink came along.
> 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. Nope, no crash. Just an unclean filesystem shutdown due to the one and only long-running process still active at that point. Back in the days before journalling filesystems, that could cause an unwanted fsck.
Whatever. Doesn't matter. The point is that prelink has to do it, in order to avoid the fallout.
If prelink's behavior did not have any damaging effects, there would be no reason to do that. Which, of course, is my point, which you are doing your best to avoid.
> Until someone explains how exec($pathname) results in two completely > different binaries getting started (excepting prelink's brain damage, and, As I already said, chroot() can cause this as well. Since there are a
And as I already said, chroot requires root privileges. And if someone has root on your box, all bets are off.
That, of course, is a completely specious argument. Which I pointed out before.
> > 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. No, you are dodging. You are the sole person claiming prelink is broken, and your sole reasoning is based on a faulty assumption. I'm
No, I'm not the sole person. Whoever wrote that wrapper for prelink, for init, also claims that.
> 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. Well, once someone has root, they could load a kernel module that
Right. And if someone has root, they can do a chroot jail too.Your argument against the value in checking /proc/pid/exe essentially boils down, here, to the fact that root can defeat it.
That, of course, is an intellectually bankrupt proposition.
> 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. It breaks _your_ daemon, because that's the only one that attempts to rely on such a broken assumption.
It's not broken, until prelink decides to rewrite every binary in the system, in an uncontrolled fashion. That's what broken, I'm just pointing it out.
> the /proc/pid/exe symbolic link names the pathname of the binary > that the process was started with. And that doesn't change - /proc/pid/exe is the pathname. However, the
Not any more. That's the point. And you know it. You just don't have the courage to face the truth.
Attachment:
pgpk_Y541eedt.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
