Jef Spaleta writes:
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik
<mrsam(a)courier-mta.com>
wrote:
> A means for authenticating a filesystem domain socket's peer. Receive the
> peer's credentials, then check /proc/pid/exe and /proc/self/exe. If they're
> same, the daemon is talking to another instance of itself.
The "same" in what sense?
I would naively assume you mean the "same" file location. Which I
would think prelink operation would still allow.
No, because, as I've pointed out, after prelink chews on a binary, it's
/proc/self/exe becomes a made-up figment of someone's imagination.
if you are doing something else...doesn't prelink's operation
prove
that such a check is invalid and that you've made some erroneous
assumptions about what what "sameness" means?
I would expect that /proc/self/exe symlink gives the name of the running
executable. I don't think it's an unreasonable expectation.
I mean, that's what the proc(5) man page says, after all.
/proc/[pid]/exe
Under Linux 2.2 and later, this file is a symbolic link contain‐
ing the actual pathname of the executed command. This symbolic
link can be dereferenced normally; attempting to open it will
open the executable. You can even type /proc/[pid]/exe to run
another copy of the same executable as is being run by process
[pid].
Not any more. At least for the first part, it is no longer the actual
pathname of the executed command. I haven't checked if the other two
properties remain true.
Prelink results in an operational "peer" instance that does
not
conform to your check. It's really seems like your check has some
baked in assumptions that are too narrow.
Well, I guess if expecting readlink("/proc/self/exe") to return my own
executable's pathname is a narrow expectation, then so be it.