On Wed, Jul 18, 2012 at 12:35 AM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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?
>> 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.
>
> I already described what I'm doing, but I don't really feel like listening
> again to someone who firmly believes that they know what I'm doing better
> than me.
I'm afraid I can't help, then. *shrug*
Just for the benefit of others and the historical record....
>> > 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
/proc. See e.g.
http://cvsweb.netbsd.org/bsdweb.cgi/src/etc/MAKEDEV.tmpl?rev=1.156&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
).
If you want to focus on symlinks with magic behavior that resolve to
something else than what readlink() returns instead,
http://en.wikipedia.org/wiki/Symbolic_link#Variable_symbolic_links .
Mirek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
