prelink should not mess with running executables

[Scott Schmit]

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?  Like it or not, that's a real
possibility ("normal" as opposed to the result of an error condition or
a bug), even if it's possibly not typical.

Well, let's see what happens:
$ echo 'int main() { while(1); }' > foo.c
$ gcc foo.c
$ ./a.out&
$ ls -ln /proc/$(jobs -p)/exe
lrwxrwxrwx. 1 1000 1000 0 Jul 16 20:27 /proc/7078/exe -> /tmp/foo/a.out
$ rm a.out
$ ls -ln /proc/$(jobs -p)/exe
lrwxrwxrwx. 1 1000 1000 0 Jul 16 20:27 /proc/7078/exe -> /tmp/foo/a.out (deleted)
$ file /proc/$(jobs -p)/exe
/proc/7078/exe: symbolic link to `/tmp/foo/a.out (deleted)'
$ file -L /proc/$(jobs -p)/exe
/proc/7078/exe: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not
stripped
$ kill %1
$ gcc foo.c
$ ./a.out &
$ gcc foo.c
$ ls -ln /proc/$(jobs -p)/exe
lrwxrwxrwx. 1 1000 1000 0 Jul 16 20:41 /proc/7898/exe -> /tmp/foo/a.out (deleted)
$ kill %1
$ ./a.out &
$ echo a >> a.out 
bash: a.out: Text file busy
$ echo a > a.out
bash: a.out: Text file busy

It gives you your current path name until that name no longer exists.
Then it tells you that your path is deleted (though you could also have
an executable ending in ' (deleted)').  If you access your file contents
via the link, you'll still get your original file contents.

That's the interface you've got. Playing around a bit, what it looks
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.  The device+inode can't be reused while you're
executing, so you know that the other program is using the same
executable (but it still might not be you, since programs can run more
than once).

> >process not being able to cope with it should be fixed.
> 
> Broken maintenance scripts, of dubiuous benefit, that randomly
> rewrite unrelated binaries, should be fixed.

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

-- 
Scott Schmit
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4104 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120716/fe789971/attachment.bin>