Once upon a time, Sam Varshavchik <mrsam(a)courier-mta.com> 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(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.