On 2011-02-18, Grant Edwards <[email protected]> wrote:
>> I'm not sure that we can ignore all cases where syscalls return file
>> descriptor as their return value.
>
> That wasn't my intent, and I don't think that's what the code does.
>
> I meant to ignore system calls who returned file descriptors (and
> therefore had the TRACE_DESC flag set), but didn't have arguments that
> were file paths or open file descriptors.
Doh! I just realized that I completely misunderstood that.
You weren't talking about sys_calls returning descriptors that were
being explicity ignored like fdtimer_create. You were refering to fd
return values from syscalls like open() that were being ignore.
I mistakenly thought the the open(symlink) example was a completely
different issue, but now I see that checking the fd returned by open
solves the problem shown in the example.
I agree that the fd's returned from open() and creat() should be
checked for a match. I'll do that. Are there others?
[...]
Do we still need to do something to deal with the symlink vs.
canonical question for syscalls like stat()?
Should we try to handle syscalls like faccessat() where the file is
specified by a (fd,relative-path) tuple?
>> For example,
>> $ strace -s4 -y -P /lib64/libc-2.11.3.so -P /lib64/libc.so.6 /bin/echo
>> open("/lib64/libc.so.6", O_RDONLY) = 3
>> read(3</lib64/libc-2.11.3.so>, "\177ELF"..., 832) = 832
>> fstat(3</lib64/libc-2.11.3.so>, {st_mode=S_IFREG|0755, st_size=1465744,
>> ...}) = 0
>> close(3</lib64/libc-2.11.3.so>) = 0
>>
>> The pathname passed to open(2) is a symlink, and /proc/<pid>/fd/<fd>
>> points to the canonicalized pathname, so -P /lib64/libc-2.11.3.so
>> won't catch this open(2) call now.
>
> I can think of a couple options:
>
> 1) Store both the canoical and "as-provided" versions of paths
> passed to -P.
>
> 2) Canonicalize the pathname passed to -P, and also canonicalize
> path arguments when checking for a match.
--
Grant Edwards grant.b.edwards Yow! Oh my GOD -- the
at SUN just fell into YANKEE
gmail.com STADIUM!!
------------------------------------------------------------------------------
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
