prelink should not mess with running executables

[Sam Varshavchik]

Miloslav Trmač writes:

> On Wed, Jul 18, 2012 at 12:35 AM, Sam Varshavchik <mrsam at courier-mta.com>  
> wrote:
> > Miloslav Trmač writes:
> >> > 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.
> >
> > Just because that you see zero value of this, and that you see no purpose
> > from it, doesn't mean that there is none.
>
> I have explained why I think the information is meaningless.  Which
> part is incorrect, or what am I assuming that is not true?

Yes, you have explained why you think it's meaningless. And I explained why  
I think it's not.

> >> > 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),
> > Really? An example of a "symbolic link pointing to a non-existent  
> pathname"?
> >
> > lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stderr → /proc/self/fd/2
> > lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdin → /proc/self/fd/0
> > lrwxrwxrwx. 1 root root 15 Jul 17 18:02 /dev/stdout → /proc/self/fd/1
>
> "Traditionally", /dev/std* were special devices, not special links to

Who said anything about the type of the file they pointed to? You must've  
meant to reply to some other post. I made no reference to the file type that  
was targeted by the symbolic link.

-------------- 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/20120717/d178befa/attachment.sig>