prelink should not mess with running executables

[Miloslav Trmač]

On Tue, Jul 17, 2012 at 4:37 AM, Sam Varshavchik <mrsam at courier-mta.com> wrote:
> Scott Schmit writes:
>> And what's the pathname of a deleted file?
>
> My point exactly. There is none. Thanks, prelink!

"Thanks, UNIX".  What is the pathname of a file with several links?
The pathnames just doesn't mean much in UNIX, and this case is _not_
particularly special.

>>                                                                  Even
>> then, the time would be better spent changing your software to use the
>> interface correctly (or use a more appropriate one) so you never have
>> problems.
>
>
> Can you explain, then, the "correctly" approach by which an executable can
> affirm whether another pid is either running the same executable, or the
> post-prelinked version of the same executable.

The executable _doesn't_ affirm that.  This affirmation has zero
security value due to ptrace(2) (or plain mmap(2) replacing the old
executable with something different), and I can't see any non-security
purpose of this check either.  If you don't tell us what you are
_actually_ trying to do, instead of fixating on a sub-task that is
impossible or meaningless in UNIX, I'm afraid you'll stay
disappointed.

> P.P.S. And I'm still trying to process the concept of a symbolic link
> pointing to a non-existent pathname; yet an open() on that somehow succeeds,
> nevertheless. That's one a headscratcher, even though I'm told that's how
> "UNIX" worked for decades. You always learn something new.

Other traditional examples: /dev/std{in,out,err} (OK, these used to be
devices rather than symlinks, but that's a trivial difference),
/proc/*/fd/* in Linux.
    Mirek