prelink should not mess with running executables

[Sam Varshavchik]

Jef Spaleta writes:

> On Sun, Jul 15, 2012 at 2:00 PM, Sam Varshavchik <mrsam at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120715/b9775ab9/attachment.sig>