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. > 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. > 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 number of FTP servers that utilize chroot() to limit file uploads to a subdirectory, a bug in one of them that allows a user to exec() something breaks your pathname assumption. That is many orders of magnitude more likely than the credential passing you claim is insufficient (thus requiring your invented pathname check) having a bug (especially since such bugs have happened in FTP servers but no such kernel bugs have happened). > > 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 merely pointing out other reasons your assumption is faulty. prelink is not broken as you claim. > 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 changes the proc filesystem code to report whatever they want when readlink() is done on /proc/<pid>/exe, or change the results of stat() when checking a particular binary (I'm pretty sure there have been rootkits that do the latter). > 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. > 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 inode that the pathname points at may have changed (or the pathname may even have been deleted). There has never been any guarantee otherwise. This is my last message in this thread. -- Chris Adams <cmadams@xxxxxxxxxx> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
