On 2011-02-18, Dmitry V. Levin <[email protected]> wrote:
> On Fri, Feb 18, 2011 at 05:03:38PM +0000, Grant Edwards wrote:
> [...]
>> Do we still need to do something to deal with the symlink vs.
>> canonical question for syscalls like stat()?
>
> We could canonicalize absolute pathname arguments. We even could
> canonicalize relative pathname arguments using /proc/$pid/cwd. But
> I'm not sure now whether we really need this or not.
Unless we check the result fd and print matching syscalls from
trace_syscall_exiting(), the same issue affects open() and create().
Seeing the flags/mode in open() calls on the "selected" path is an
important one of my requirements, but I can live with the requirement
that the user to provide absolute, canonical paths to the -P option if
they want to see syscalls like open/creat/stat.
I would think that concatenating /proc/$pid/cwd and a realtive path
argument, and then calling realpath() on the result would work right
the vast majority of the time.
Whether we want to try to canonicalize path arguments is up to you.
For the openat() type calls, I would thing that concatenating
/proc/$pid/fd/$fd and the path argument and then calling realpath on
that would also work most of the time.
I'll try to think up other options...
>> Should we try to handle syscalls like faccessat() where the file is
>> specified by a (fd,relative-path) tuple?
>
> We could implement a simple check, e.g. concatenate getpath(fd) with
> relative-path (or if fd == AT_FDCWD, readlink(/proc/$pid/cwd) with
> relative-path), and try to match this concatenation.
>
> But whether we need to match against canonicalized concatenation,
> I cannot say now.
>
> BTW, print_dirfd() should use printfd().
Done.
--
Grant Edwards grant.b.edwards Yow! OVER the underpass!
at UNDER the overpass!
gmail.com Around the FUTURE and
BEYOND REPAIR!!
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Strace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/strace-devel
