Advanced and improved absolute paths decoding

[Philippe Ombredanne]

On Sun, Mar 2, 2014 at 12:44 PM, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Sun, Mar 02, 2014 at 11:54:57AM +0100, Philippe Ombredanne wrote:
>> On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
>>
>> > Fourth, I think -yy should also "canonicalize" socket descriptors, i.e.
>> > print their addresses in <> form, resembling lsof(8) output.  This would
>> > be a really nice feature.
>>
>> Indeed that would be awesome and help a lot with tracing network related calls.
>>
>> I think you meant this lsof output, for instance from a wget invocation:
>>
>> COMMAND     PID        USER   FD   TYPE    DEVICE SIZE/OFF     NODE NAME
>> wget    3695865 pombredanne    3u  IPv4 125707086      0t0      TCP
>> myhost.local:56120->ch3.sourceforge.net:http (ESTABLISHED)
>>
>> How would you report this?
>>
>> Would this work for the example above?:
>> 3<socket:[125707086] IPv4, TCP, "myhost.local:56120",
>> "ch3.sourceforge.net:http">
>> where:
>> - IPv4 would be the type as reported by lsof(8)
>> - TCP, "myhost.local:56120" and  "ch3.sourceforge.net:http" would the
>> parts of the node name as reported by lsof(8)
>
> Employing network address resolving in strace is risky because of
> potentially huge delays it may cause.
> By mentioning "lsof" I rather meant "lsof -n".

Good point, lsof-like reverse DNS lookup kind of call would be a
killer and fragile too.
I always wondered why this is a default for lsof btw

> The exact output format may vary, but the general idea of strace decoding
> is to mimic C syntax.  From this PoV, path names should always be enclosed
> in double quotes.  Unfortunately, in case of -y output this rule hasn't
> been enforced, so you cannot distinguish a socket with inode 1234567 with
> a file named "socket:[1234567]".

The someone naming a file "socket:[1234567]" ought to get at least a
good slap on the wrist :D
On the other hand, this could be a mistake and one that strace could
help debug and find
Now could this be something that could be fixed as part of advanced
path decoding?
or is it really worth adding quotes around all decoded "real" paths to
care for such a rare case?

-- 
Philippe Ombredanne

On Sun, Mar 2, 2014 at 12:44 PM, Dmitry V. Levin <ldv at altlinux.org> wrote:
> On Sun, Mar 02, 2014 at 11:54:57AM +0100, Philippe Ombredanne wrote:
>> On Wed, Feb 26, 2014 at 2:28 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:
>>
>> > Fourth, I think -yy should also "canonicalize" socket descriptors, i.e.
>> > print their addresses in <> form, resembling lsof(8) output.  This would
>> > be a really nice feature.
>>
>> Indeed that would be awesome and help a lot with tracing network related calls.
>>
>> I think you meant this lsof output, for instance from a wget invocation:
>>
>> COMMAND     PID        USER   FD   TYPE    DEVICE SIZE/OFF     NODE NAME
>> wget    3695865 pombredanne    3u  IPv4 125707086      0t0      TCP
>> myhost.local:56120->ch3.sourceforge.net:http (ESTABLISHED)
>>
>> How would you report this?
>>
>> Would this work for the example above?:
>> 3<socket:[125707086] IPv4, TCP, "myhost.local:56120",
>> "ch3.sourceforge.net:http">
>> where:
>> - IPv4 would be the type as reported by lsof(8)
>> - TCP, "myhost.local:56120" and  "ch3.sourceforge.net:http" would the
>> parts of the node name as reported by lsof(8)
>
> Employing network address resolving in strace is risky because of
> potentially huge delays it may cause.
> By mentioning "lsof" I rather meant "lsof -n".
>
> The exact output format may vary, but the general idea of strace decoding
> is to mimic C syntax.  From this PoV, path names should always be enclosed
> in double quotes.  Unfortunately, in case of -y output this rule hasn't
> been enforced, so you cannot distinguish a socket with inode 1234567 with
> a file named "socket:[1234567]".
>
>
> --
> ldv
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Strace-devel mailing list
> Strace-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/strace-devel
>



-- 
Philippe Ombredanne

+1 650 799 0949 | pombredanne at nexB.com
DejaCode Enterprise at http://www.dejacode.com
nexB Inc. at http://www.nexb.com

CONFIDENTIALITY NOTICE:  This e-mail (including attachments) may
contain information that is proprietary or confidential. If you are
not the intended recipient or a person responsible for its delivery to
the intended recipient, do not copy or distribute it. Please
permanently delete the e-mail and any attachments, and notify us
immediately at (650) 799 0949.