Certain dtrace programs, particularly ones that only require the
dtrace_proc and dtrace_user privileges, should work in a non-global
zone (though obviously be restricted to the processes in that zone).
This will become increasingly important as more monitoring and debugging
tools are built using dtrace.
This RFE is more or less an umbrella for getting DTrace working
inside a zone. Other relevant CRs are:
6231905 PRIV_DTRACE_PROC and PRIV_DTRACE_USER don't respect PRIV_PROC_ZONE
6388070 non-root non-global zone users can't get dtrace provider modules to load
6393431 dtrace_proc + proc_owner doesn't sufficiently enable destructive actions
The main things which are needed to resolve this:
- Correct the DTrace/zones/privileges interactions
- Add the DTrace devices to zones
- Make sure said devices have the right permissions
This work is dependent upon
4966416 RFE: zone privileges should be configurable
And requires that the global administrator intervene to assign dtrace_user,
dtrace_proc or both to zones which should be able to use DTrace. dtrace_kernel
is never permitted inside of a zone, and a zone may never use the destructive
actions which require ALL privs: chill(), panic(), breakpoint().