dtrace discuss - May 2006 - tracing a process tree under security restrictions

I''m trying to write a dtrace script that end users can run (after
giving
themselves dtrace_proc and dtrace_user) to find the process-id
of a specific program ("prog") that''s run someplace within a
script.
(Or a child process of the script)

It''s easy for me to use the syscall provider to trace
the exec of "prog".  But when I run it like so:

dtrace -n ''syscall::exec*:return /execname=="prog"/ \
     { printf("hello %d\n", pid); } -c my_script

I end up picking up all the executions of "prog" the the
user is running anywhere on the system, not just the ones
underneath my_script.

I could build an incremental list of pids that I am
watching, and then condition on that, but I need a
way to detect the ppid/pid connection on some system
call someplace.  I can''t find a way to do that which
is valid without the dtrace_kernel permission.

Any help for me?

The list of facilities available without dtrace_kernel or
root permissions seems to be described rather tersely,
and the set seems too small.  Should the user have access
to all the structures they could normally access through /proc?
In a normal scripting language I would say just run "pargs"
or "pflags" and read the output, but you can''t do that from
inside a D script.  dtrace lives in its own world, so you need
to be able to get all the info you need through a dtrace
facility, right?

--chris

Chris Quenelle wrote:
> 
> I''m trying to write a dtrace script that end users can run (after
giving
> themselves dtrace_proc and dtrace_user) to find the process-id
> of a specific program ("prog") that''s run someplace
within a script.
> (Or a child process of the script)
> 
> It''s easy for me to use the syscall provider to trace
> the exec of "prog".  But when I run it like so:
> 
> dtrace -n ''syscall::exec*:return /execname=="prog"/ \
>     { printf("hello %d\n", pid); } -c my_script
> 
> I end up picking up all the executions of "prog" the the
> user is running anywhere on the system, not just the ones
> underneath my_script.
> 
> I could build an incremental list of pids that I am
> watching, and then condition on that, but I need a
> way to detect the ppid/pid connection on some system
> call someplace.  I can''t find a way to do that which
> is valid without the dtrace_kernel permission.
> 
> Any help for me?
> 
> The list of facilities available without dtrace_kernel or
> root permissions seems to be described rather tersely,
> and the set seems too small.  Should the user have access
> to all the structures they could normally access through /proc?
> In a normal scripting language I would say just run "pargs"
> or "pflags" and read the output, but you can''t do that
from
> inside a D script.  dtrace lives in its own world, so you need
> to be able to get all the info you need through a dtrace
> facility, right?
> 
> --chris
> 
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
Use /progenyof($target)/.

- Bart


-- 
Bart Smaalders			Solaris Kernel Performance
barts at cyber.eng.sun.com		http://blogs.sun.com/barts

On Tue, May 30, 2006 at 08:56:58PM -0700, Chris Quenelle
wrote:
> I''m trying to write a dtrace script that end users can run (after
giving
> themselves dtrace_proc and dtrace_user) to find the process-id
> of a specific program ("prog") that''s run someplace
within a script.
> (Or a child process of the script)
> 
> It''s easy for me to use the syscall provider to trace
> the exec of "prog".  But when I run it like so:
> 
> dtrace -n ''syscall::exec*:return /execname=="prog"/ \
>     { printf("hello %d\n", pid); } -c my_script
> 
> I end up picking up all the executions of "prog" the the
> user is running anywhere on the system, not just the ones
> underneath my_script.
> 
> I could build an incremental list of pids that I am
> watching, and then condition on that, but I need a
> way to detect the ppid/pid connection on some system
> call someplace.  I can''t find a way to do that which
> is valid without the dtrace_kernel permission.
You want progenyof() -- see the docs and/or google "dtrace progenyof".

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

Thanks Brian and Bart,
progenyof() works like a charm.

Clearly there are not enough dtrace web pages as long as google
keeps suggesting that I misspelled "dtrace" and I really want
to search for "strace".   ;-)

--chris


Bart Smaalders wrote:
> Chris Quenelle wrote:
> 
>>
>> I''m trying to write a dtrace script that end users can run
(after giving
>> themselves dtrace_proc and dtrace_user) to find the process-id
>> of a specific program ("prog") that''s run someplace
within a script.
>> (Or a child process of the script)
>>
>> It''s easy for me to use the syscall provider to trace
>> the exec of "prog".  But when I run it like so:
>>
>> dtrace -n ''syscall::exec*:return /execname=="prog"/
\
>>     { printf("hello %d\n", pid); } -c my_script
>>
>> I end up picking up all the executions of "prog" the the
>> user is running anywhere on the system, not just the ones
>> underneath my_script.
>>
>> I could build an incremental list of pids that I am
>> watching, and then condition on that, but I need a
>> way to detect the ppid/pid connection on some system
>> call someplace.  I can''t find a way to do that which
>> is valid without the dtrace_kernel permission.
>>
>> Any help for me?
>>
>> The list of facilities available without dtrace_kernel or
>> root permissions seems to be described rather tersely,
>> and the set seems too small.  Should the user have access
>> to all the structures they could normally access through /proc?
>> In a normal scripting language I would say just run "pargs"
>> or "pflags" and read the output, but you can''t do
that from
>> inside a D script.  dtrace lives in its own world, so you need
>> to be able to get all the info you need through a dtrace
>> facility, right?
>>
>> --chris
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
> 
> 
> Use /progenyof($target)/.
> 
> - Bart
> 
>

Thats a flaw in the architecture of Google.  It assumes more independent hits is
better.:-) One of the reasons there aren''t lots of web pages for DTrace
is because the original documentation is so good that there isn''t a
need for lots of supplementary docs :-)
 
 
This message posted from opensolaris.org