Advanced and improved absolute paths decoding

[eQuiNoX]

Thank you for your reply, Dmitry!


On Wed, Feb 26, 2014 at 6:58 AM, Dmitry V. Levin <ldv at altlinux.org> wrote:

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

I see, cool stuff.


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

I should probably go read the source instead -- is there any other way to
get information about an intercepted system call other than from the struct
tcb?


>
> 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.
>
>
Great stuff, thank you very much !


Also, is there an IRC channel for strace dev?



Cheers,
zm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140226/f59c97bc/attachment.html>