Hey Paul,
> Thanks for the info - I guess this sort of is asking for it, but
> exactly how did you know that 5 was the right number to grep for,
> aside from knowing the kernel?
Take a look a that link in my last message -- it's the source code for
the
fsat system call. You'll see that code 5 is unlinkat(2). As I said
before,
this state really isn't ideal; it would be great if we had something a
bit
better for this type of system call (getcontext(2) and setcontext(2) are
other examples of system calls subcodes that share a single system
call).
> Also, isn't stop, being a destructive actions, not allowed without
> dtrace_kernel privilege? Shouldn't I - as a user, be able to add
> destructive actions that modify my own processes, and nobody else's?
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.
> To the first point, IMO, there should be an 'intelligent' copyinstr
> - one that is able to either dereference if needed, and one that
> converts common numbers like the above into human-readable actions.
> I'd love to be able to say:
>
> dtrace -n 'syscall:::entry { @[ execname, pid, probefunc,
> copyinstr(arg0, arg1, arg2) ] = count(); }'
>
> and not have to worry whether a given function had 3 arguments or 2
> or 1 -- that it would do the right thing and basically give me human
> readable output for all system calls on the system without need for
> lots of programming. (the other place this would be helpful for is
> door calls. I'm still not sure how to trace past these.)
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? It's a reasonable request, but I
don't
think we'll be implementing it any time soon. 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.
> As for the second point, IMO there has got to be a level between
> dtrace_user and dtrace_kernel, perhaps 2 - one where you can effect
> (ie: have destructive actions) on your own processes, and one where
> you can effect and/or trace processes in your own groups - often,
> the functions I need to trace past are ones done by, say a web
> server, and I don't want to need sudo or root privilege to do this.
> Just MO.
Take a look at the docs and let me know if you're still unhappy with the
privileges we've provided. I think you'll find that the situation is
pretty
much as you desire.
> (PS: can you write user-based dtrace functions? that would be a
> quick fix for the intelligent copyinstr feature.. and would come in
> helpful in a myriad of ways..)
Nope. There's nothing like that.
Adam
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
[email protected]
