prelink should not mess with running executables

[Sam Varshavchik]

Scott Schmit writes:

> On Mon, Jul 16, 2012 at 07:38:52PM -0400, Sam Varshavchik wrote:
> > Jan Kratochvil writes:
> >
> > >On Sun, 15 Jul 2012 22:42:00 +0200, Sam Varshavchik wrote:
> > >> And I wouldn't be so presumptions as to state authoritatively what
> > >> is or is not a bug, in something whose purpose is not known to me.
> > >
> > >Non-existing /proc/self/exe file is a normal UNIX process state so a UNIX
> >
> > It is anything but "normal". The "normal" state of things is
> > documented by proc(5). As documented by that man page, rather
> > plainly, readlink("/proc/self/exe") gives you your own pathname.
> > That's the "normal" state of things, if "normal" means anything.
> > When that no longer holds true, that's not "normal".
>
> And what's the pathname of a deleted file?

My point exactly. There is none. Thanks, prelink!

...

> That's the interface you've got. Playing around a bit, what it looks

That's a very nice explanation. Unfortunately, all of these semantics are  
not under question. That's not the issue.

> like you want to do is open("/proc/self/exe", O_RDONLY), fstat the
> resulting file descriptor, and use the device+inode to compare to the
> "other" executables.

Which will, of course, be different. Because prelink rewrote and renamed the  
executable. I'm not exactly sure what point you were trying to make,  
other than prelink being broken by design.

>                      The device+inode can't be reused while you're
> executing, so you know that the other program is using the same
> executable

No, it's not using the same executable. The executable has been replaced by  
prelink, and the executable is now different, even though it is, really, the  
same executable. Nothing has been installed, or upgraded.

> Expecting every other program that manipulates/replaces files to cater
> to your expectations is not reasonable unless you have 100% control over
> everything that runs on your system (and take full responsibilty for
> controlling it) and likewise for anyone else using the software.

True. That 100% control, of course, includes uninstalling the pest that  
keeps rewriting executables, any time it feels like it.

>                                                                  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. Anyone who suggests readlink- 
ing /proc/self/exe, then the other /proc/pid/exe, and comparing them sans  
any hardcoded " (deleted)" suffix is going to get only howls of laughter, in  
response.

P.S. I have an internal betting pool going on when some top gun offers a  
suggestion of running prelink --verify on both exe-s (since you can still  
open a " (deleted)" exe, inexplicably, even though the actual symlink points  
to nowhere), and comparing the results.

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.

-------------- 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/20120716/493a8e43/attachment.sig>