This is pretty cool because it brings some of the observational power of DTrace
to the folks deploying applications inside of non-global zones. In future
Solaris Express and Community
Release builds (those based on Nevada b37 and higher), you can use a subset of
DTrace functionality as follows:
# zonecfg -z myzone zonecfg:myzone> set limitpriv=default,dtrace_proc,dtrace_user zonecfg:myzone> \^D # zoneadm -z myzone boot # zlogin myzone myzone# dtrace -l ... myzone# plockstat -Ap `pgrep startd` ...
Note that either or both of the dtrace_proc and
dtrace_user privileges may be granted to a zone, but
dtrace_kernel may not be (zoneadm will enforce this). The lack of
dtrace_kernel means that not every DTrace script will work, since
kernel state is not available to DTrace inside of a zone; but we think this
represents a good start.
Additional virtualization work has been done to ensure that data from
other zones is not visible inside the zone, and to ensure that the
interactions with other relevant privileges (proc_owner and
proc_zone) behave as expected.
For those interested in how this was accomplished, the following bugs
should be helpful:
RFE: should be able to run some DTrace programs in a zone
libdtrace should interrogate providers, open devices via /dev.
non-root non-global zone users can’t get dtrace provider modules to load
dtrace_proc + proc_owner doesn’t sufficiently enable destructive actions
All of this rests on David’s work
to make zone privileges configurable.