Jef Spaleta writes:
On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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.
Attachment:
pgpMCrLMVVpKP.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
