prelink should not mess with running executables

[Sam Varshavchik]

Miloslav Trmač writes:

> 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?

Doesn't matter, either one of them is fine.

> The pathnames just doesn't mean much in UNIX, and this case is _not_
> particularly special.

Yes, let's get rid of filesystems, and store everything in a relational  
database. Isn't that something that a convicted monopolist tried to do, the  
other day?

> >
> > 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.

>                              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.

> > 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

You mean to tell me that none of those symlinks exist? Could've fooled me:

[mrsam at eee900 /]$ ls -al /proc/self/fd/{0,1,2}
lrwx------. 1 mrsam mrsam 64 Jul 17 18:31 /proc/self/fd/0 → /dev/pts/1
lrwx------. 1 mrsam mrsam 64 Jul 17 18:31 /proc/self/fd/1 → /dev/pts/1
lrwx------. 1 mrsam mrsam 64 Jul 17 18:31 /proc/self/fd/2 → /dev/pts/1

But they do!

crw--w----. 1 mrsam tty 136, 1 Jul 17 18:31 /dev/pts/1

And that symlink exists as well! And I can even open it!

[mrsam at eee900 /]$ cat /dev/pts/1

Wow, what a novel concept.

So, can you try again, with an example of a symlink that points to a non- 
existent pathname, yet one that can be open(), like /proc/self/exe →  
"$filename (deleted)" can.

But, again, that's a sideshow and a distraction. That's not a problem, or an  
issue, of course. The problem is prelink invalidating the symlink, with the  
sorry excuses from the "duh… but you can still open it" crowd, who are  
incapable of understanding what the issue is.

-------------- 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/55688111/attachment-0001.sig>