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
pgpObTeKcH7uV.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel
