RFC: path display and path filtering features.

[Grant Edwards]

On 2011-02-18, Dmitry V. Levin <ldv at altlinux.org> wrote:

>> I'm going to work on checking the fd's referred in the args to the
>> poll/select calls.
>
> OK
>
>> Are there other calls in that list that have
>> path/fd arguments that should be tested?  
>
> printargs is used to handle a few syscalls that have no individual
> parsers yet.  Some of them have path/fd arguments that should be tested,
> e.g. splice, sync_file_range, vmsplice.

Since they all have s->sys_func == printargs, testing the value of
s->sys_func isn't useful.  The system call numbers aren't consistent
across architectures, so that's no help.  I guess I'll have to check
the name strings of the calls handled by printargs.

>> > 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 canonical and "as-provided" versions of paths
>>     passed to -P.
>
> Agreed, it could be useful for absolute paths passed to -P.


>>  2) Canonicalize the pathname passed to -P, and also canonicalize
>>     path arguments when checking for a match. 
>
> No, canonicalizing path arguments is unreliable, first of all because
> of relative pathnames.

OK, then I'll go with #1.  Paths passed to -P will be stored both
as-is and canonicalized.  System calls with path arguments who match
either will be displayed.

-- 
Grant Edwards               grant.b.edwards        Yow! If Robert Di Niro
                                  at               assassinates Walter Slezak,
                              gmail.com            will Jodie Foster marry
                                                   Bonzo??