> Take a look at the chapter on DTrace privileges:
> http://wikis.sun.com/display/DTrace/Security
> Note that stop() can be applied to processes to which you have sufficient
> privileges to modify.
Did this change in recent versions of dtrace? I'm not seeing this work:
syscall::fsat:entry /arg0 == 5/
{
stop();
printf("%d %s %d %s\n", pid, execname, arg0, copyinstr(arg1));
system("ptree %d", pid); system("prun %d", pid);
}
dtrace: script '/tmp/del.d' matched 1 probe
dtrace: could not enable tracing: Destructive actions not allowed
> let me see if I understand your request: basically, you want some way to
> say "print out all the arguments to this probe formatted in a way that
> makes some sense" -- is that right?
Basically, but let me put it a bit differently. I want the 'new copyinstr' to
be able to use introspection on the probefunc to determine how to treat the
given arguments and to transform them into a format that becomes human readable
(if possible).
I cannot stress how much easier that this would make dtrace to use. Every
single major scripting language out there has a 'dumper' function that can
intelligently parse data structures (even gdb has the ability); dtrace should
be no exception. For system calls, If the arg array had the probefunc attached
to it as a property, then you could pass it to such a function and have a
lookup table on how to treat the arguments.
A pointer to the arg array would help too (does it exist?) so you could pass
the entire array to this function; the ability to stringify data structures
behind args would help as well.
> Perhaps this would be an opportunity for a third party to build some layered
> software to implement your suggestion. That is, one could write a program
> that consumed CTF data to generate a D script that did what you described.
Great, I'm a third party.. ;) From my point of view, I think that generating it
from headers might be easier, especially if I could program it in a dtrace
function of my own design, and just look at the headers i'm most interested in.
Come to think of it - exactly how could you scale up such a generated program
that doesn't use user function calls? Suppose I wanted to use the intelligent
copystr in my own program in a myriad of places - are you really suggesting
that having an interpreter which takes user-level functions and expands them in
my source code is the best way to do it?
I think you guys should just bite the bullet and make user-level functions.. I
don't think you'd even need to make kludgy syntax for it - just inherit from
python or perl:
user::intelligent_copystr
{
printf ("%a", @args);
}
Thanks much,
Paul
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]
