Miloslav Trmač writes:
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?
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.
Attachment:
pgppgOEhXEwkF.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
