Advanced and improved absolute paths decoding

[Dmitry V. Levin]

Hi,

On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:
> Hey all,
> 
> I'm Zubin and I love low level systems programming! :)

Great! :)

> A little about myself, I program primarily in C and Python, have systems
> programming experience with Minix(filesystem development) and Linux and am
> a hobbyist reverse engineer(I play CTF security exercises) -- and thats
> when I use strace the most !
> 
> I had a look at the ideas list here[1] and found the idea on improved path
> decoding quite interesting and was hoping we could discuss it further on
> the mailing list.
> 
> I had a quick look at the implementation of the -y flag and noticed the
> implementation of getfdpath(where the magic seemed to be happening). It
> seemed to be trying to read the value of the symbolic link at
> /proc/<pid>/fd/<fd>.
> 
> Is my understanding of the following accurate?

Yes, getfdpath() is the single point where strace fetches the path
corresponding to the given descriptor.

Besides that, printfd() is the single point where this fetched path is
currently printed.  The path fetched by getfdpath() is also used by
fdmatch() to implement -P option.

> Modifications need to be made such that upon using the "yy" flag:-
> - Calls to functions that take a path as an argument are displayed with the
> absolute path regardless of the argument that is passed in.

I suppose path arguments should be printed the same way as they are
printed now, and, in addition, if -yy mode is specified, canonicalized
paths should be printed in <> form.

> - When calls to functions that return a file descriptor are made, the
> absolute path to the filename corresponding to the file descriptor needs to
> be printed

I think yes, probably by means of printfd().

> - Same as above for functions that use path/descriptor combos.

Right.

In addition, there are at* functions: to canonicalize their path arguments,
dirfd argument also has to be taken into account.

> I believe that the first step would be to document and note down the system
> calls that belong to one or more of the above categories and their system
> call numbers, and if the -yy flag is used, check the tcp->scno against
> these numbers and act accordingly.
> 
> Is there something I'm missing? I'd love any kind of feedback!

You probably don't need to care about tcp->scno to implement -yy mode.

First, since all descriptors (should be) printed using printfd(), you just
use it to decode returned descriptors.

Second, since all paths are printed using printpath() or printpathn(), it
should be enough to extend this scheme for decoding path arguments of
regular and at* functions in -yy mode.

Third, -yy mode should extend -P functionality, this means that path
arguments matching should work with canonicalized pathnames.

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


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140226/e33bffd8/attachment.bin>