<div dir="ltr">Thank you for your reply, Dmitry! <br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 6:58 AM, Dmitry V. Levin <span dir="ltr"><<a href="mailto:ldv@altlinux.org" target="_blank">ldv@altlinux.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><br>
On Tue, Feb 25, 2014 at 10:27:37PM +0530, Zubin Mithra wrote:<br>
> Hey all,<br>
><br>
> I'm Zubin and I love low level systems programming! :)<br>
<br>
</div>Great! :)<br>
<div><br>
> A little about myself, I program primarily in C and Python, have systems<br>
> programming experience with Minix(filesystem development) and Linux and am<br>
> a hobbyist reverse engineer(I play CTF security exercises) -- and thats<br>
> when I use strace the most !<br>
><br>
> I had a look at the ideas list here[1] and found the idea on improved path<br>
> decoding quite interesting and was hoping we could discuss it further on<br>
> the mailing list.<br>
><br>
> I had a quick look at the implementation of the -y flag and noticed the<br>
> implementation of getfdpath(where the magic seemed to be happening). It<br>
> seemed to be trying to read the value of the symbolic link at<br>
> /proc/<pid>/fd/<fd>.<br>
><br>
> Is my understanding of the following accurate?<br>
<br>
</div>Yes, getfdpath() is the single point where strace fetches the path<br>
corresponding to the given descriptor.<br>
<br>
Besides that, printfd() is the single point where this fetched path is<br>
currently printed.  The path fetched by getfdpath() is also used by<br>
fdmatch() to implement -P option.<br>
<div><br>
> Modifications need to be made such that upon using the "yy" flag:-<br>
> - Calls to functions that take a path as an argument are displayed with the<br>
> absolute path regardless of the argument that is passed in.<br>
<br>
</div>I suppose path arguments should be printed the same way as they are<br>
printed now, and, in addition, if -yy mode is specified, canonicalized<br>
paths should be printed in <> form.<br></blockquote><div><br></div><div>I see, cool stuff.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> - When calls to functions that return a file descriptor are made, the<br>
> absolute path to the filename corresponding to the file descriptor needs to<br>
> be printed<br>
<br>
</div>I think yes, probably by means of printfd().<br>
<div><br>
> - Same as above for functions that use path/descriptor combos.<br>
<br>
</div>Right.<br>
<br>
In addition, there are at* functions: to canonicalize their path arguments,<br>
dirfd argument also has to be taken into account.<br>
<div><br>
> I believe that the first step would be to document and note down the system<br>
> calls that belong to one or more of the above categories and their system<br>
> call numbers, and if the -yy flag is used, check the tcp->scno against<br>
> these numbers and act accordingly.<br>
><br>
> Is there something I'm missing? I'd love any kind of feedback!<br>
<br>
</div>You probably don't need to care about tcp->scno to implement -yy mode.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
First, since all descriptors (should be) printed using printfd(), you just<br>
use it to decode returned descriptors.<br>
<br>
Second, since all paths are printed using printpath() or printpathn(), it<br>
should be enough to extend this scheme for decoding path arguments of<br>
regular and at* functions in -yy mode.<br>
<br>
Third, -yy mode should extend -P functionality, this means that path<br>
arguments matching should work with canonicalized pathnames.<br>
<br>
Forth, I think -yy should also "canonicalize" socket descriptors, i.e.<br>
print their addresses in <> form, resembling lsof(8) output.  This would<br>
be a really nice feature.<br>
<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>Great stuff, thank you very much !</div><div><br></div><div><br></div><div>Also, is there an IRC channel for strace dev?</div><div><br></div>
<div><br></div><div><br></div><div>Cheers,</div><div>zm</div></div></div></div>