new command fexe

new command fexe

[Andrew Cagney]

This is from the man page:

$ cp /bin/bash /tmp/sh
$ PS1=Â’sh$ Â’ /tmp/sh
sh$ fexe $$
/tmp/sh
sh$ rm /tmp/sh
sh$ fexe -v $$
1234 null /tmp/sh (deleted)

Re: new command fexe

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 436 bytes --]

Hi Andrew,

On Wed, 2007-07-18 at 15:18 -0400, Andrew Cagney wrote:
> This is from the man page:
> 
> $ cp /bin/bash /tmp/sh
> $ PS1=’sh$ ’ /tmp/sh
> sh$ fexe $$
> /tmp/sh
> sh$ rm /tmp/sh
> sh$ fexe -v $$
> 1234 null /tmp/sh (deleted)

Can you use this to show that soft link bug a softlink contains a \0
character in it? It would be good to have a showcase of that so we can
report it upstream.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new command fexe

[Andrew Cagney]

Mark, something like this:

cagney@nettle$ cp /bin/bash /tmp
cagney@nettle$ /tmp/bash
cagney@nettle$ cp /bin/bash /tmp/a-very-long-file
cagney@nettle$ mv !$ /tmp/bash
mv /tmp/a-very-long-file /tmp/bash
cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe $$
null
cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe -v $$
3905 null /tmp/bash4]setspeed (deleted)
cagney@nettle$

?

Mark Wielaard wrote:
> Hi Andrew,
>
> On Wed, 2007-07-18 at 15:18 -0400, Andrew Cagney wrote:
>   
>> This is from the man page:
>>
>> $ cp /bin/bash /tmp/sh
>> $ PS1=’sh$ ’ /tmp/sh
>> sh$ fexe $$
>> /tmp/sh
>> sh$ rm /tmp/sh
>> sh$ fexe -v $$
>> 1234 null /tmp/sh (deleted)
>>     
>
> Can you use this to show that soft link bug a softlink contains a \0
> character in it? It would be good to have a showcase of that so we can
> report it upstream.
>
> Cheers,
>
> Mark
>   

Re: new command fexe

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

Hi Andrew,

On Wed, 2007-07-25 at 12:24 -0400, Andrew Cagney wrote:
> cagney@nettle$ cp /bin/bash /tmp
> cagney@nettle$ /tmp/bash
> cagney@nettle$ cp /bin/bash /tmp/a-very-long-file
> cagney@nettle$ mv !$ /tmp/bash
> mv /tmp/a-very-long-file /tmp/bash
> cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe $$
> null
> cagney@nettle$ /home/scratch/frysk/native/frysk-core/frysk/bindir/fexe -v $$
> 3905 null /tmp/bash4]setspeed (deleted)
> cagney@nettle$

Very interesting. It doesn't really depend on the something very-long,
just something with a longer path than the original. Also, it goes away
if in between any of these commands you actually examine /proc/$$/exe
first.

Looking at the kernel code I couldn't immediately find a fix, but it is
at least hinted at in fs/dcache.c that the result looks ugly for things
like open files in /proc that get deleted by a move. It also say "We
could be more polite about it, though." But I didn't see some simple
fix.

But this highlights the fact that it really is a fake symlink. Which you
cannot really trust at all except for displaying something human
readable as needed in the gui, but you shouldn't use it for trying to
get at the Elf image as done in the core, in that case you have to open
the original /proc/pid/exe directly. So we really need 2 interfaces here
to satisfy the 2 different ways getExe() is used. One to get the symlink
name to display and one to get at the file to open to get the actual exe
image (even when the original exe got moved or deleted).

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: new command fexe

[Andrew Cagney]

Mark Wielaard wrote:

Yes, frysk needs access to at least:
-> the exe when the program started
-> what might be the exe now with a well defined failure mode (a blank 
link would be better than "(deleted)"
(there's also the last known good exe but that is getting contrived :-)
I believe moller's user-land utrace interface makes these available.

Andrew

> But this highlights the fact that it really is a fake symlink. Which you
> cannot really trust at all except for displaying something human
> readable as needed in the gui, but you shouldn't use it for trying to
> get at the Elf image as done in the core, in that case you have to open
> the original /proc/pid/exe directly. So we really need 2 interfaces here
> to satisfy the 2 different ways getExe() is used. One to get the symlink
> name to display and one to get at the file to open to get the actual exe
> image (even when the original exe got moved or deleted).
>
> Cheers,
>
> Mark
>