|
Tuesday June 29, 2004
dtrace new features and schedule
Adam Leventhal has announced some nice new additions to dtrace, and a rough idea of when you may see these in Solaris Express. Theres lots of nice new features, but my personal favourite for today is the new -c option. And combining it with -x, and -p, and, oh okay, I'll stop. Suffice to say I won't be using truss on s10 again. You can view the dtrace Solaris Express schedule here.
(2004-06-29 06:52:50.0)
Permalink
Giving a user privileges to run dtrace
One of the litany of new features that has been added to Solaris 10 (which of course you can download via the Solaris Express program) is a new fine grained privilege model put in place by Casper Dik, (blog).
Privileges and all of its associated configuration is documented in the Security Services section of the S10 System Administration Guide. Personally I like to use privileges to allow me to use dtrace on my own stuff without having to su to root every time, so heres how you set this up.
First off, lets say I don't have any privileges to run dtrace, and I try to execute it as myself on one of my own processes. In this case I want to take a look at what one of my other shells is doing
$ ps -fU fintanr | sed -e "/$$/d" | grep ksh
UID PID PPID C STIME TTY TIME CMD
fintanr 8995 1310 0 12:19:06 pts/3 0:00 -ksh
fintanr 8969 1439 0 12:13:26 pts/11 0:00 -ksh
$ dtrace -n 'pid8995:libc.so.1::entry'
dtrace: failed to initialize dtrace: DTrace requires additional privileges
And so it fails. Now while this is nice and prevents people messing around with dtrace, lets say your a sysadmin and you have provided an Solaris Express box for your local developers to play with, but being a sysadmin, you don't want to give them the root password so that they can run dtrace (and being developers mess up your nicely configured machine by changing every available setting as well). So in this case the username is fintanr, so I run.
usermod -K defaultpriv=basic,dtrace_proc,dtrace_user fintanr
Which will give me access to my own processes in userland. I could also add in dtrace_kernel to these privileges as well. So now I fire up dtrace on the same ksh process that I was looking at above.
$ /usr/sbin/dtrace -n 'pid8995:libc.so.1::entry'
dtrace: description 'pid8995:libc.so.1::entry' matched 2471 probes
dtrace: buffer size lowered to 2m
CPU ID FUNCTION:NAME
0 44225 lseek64:entry
0 43686 read:entry
0 43985 _save_nv_regs:entry
0 44119 _read:entry
..............
And I can now take a look at whats going on.
More info on the dtrace security model is available in the dtrace answerbook.
(2004-06-29 05:16:37.0)
Permalink
|
