prelink should not mess with running executables

[Sam Varshavchik]

Bryn M. Reeves writes:

> On 07/17/2012 12:38 AM, 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".
>
> As others have pointed out it is a normal situation that the system has
> to deal with;

No, I'm afraid it's not "normal", by any sense of the word, for something to  
randomly delete executables, and replace them with similarly looking files.

>               there's no escaping it on a UNIX-like OS and a developer

Yes, there's certainly a guaranteed way to "escape" it. It's called "don't  
do stupid things". What a novel concept.

> can never depend on it not happening at "random" times.
>
> The pathname that is returned to readlink(2) doesn't exist in the file
> system (how could it?) but the proc path is still valid for IO and the
> inode will not be de-allocated while it is open:

Except that's not what proc(5) says. As described, reading that symlink  
should give you the executable's name. Except, in this situation, it no  
longer does. It points to a non-existent pathname. The fact that by some  
miracle of miracles an open() on a non-existent pathname manages to succeed,  
is an irrelevant sideshow.

> If you're happy to accept something that's a different version of the
> binary

I'm not.

>        then I'm not sure why you need to read the executable (what are

When did I ever said that I needed to read the executable?

> you checking in it?). If it's just an inode number match it's hard to
> see what that achieves.

Just because you find it hard to see "what that achieves", means only that:  
you find it hard to see.

> > Broken maintenance scripts, of dubiuous benefit, that randomly rewrite
> > unrelated binaries, should be fixed.
>
> Suggest fixes. If you're doing something unusual the onus is on you to

Well, I did.

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