All, A(nother) longstanding DTrace annoyance has been that tick probes, while enableable by users with limited privilege, will only fire if the context matches one that the user is allowed to instrument. Specifically: if a user uses tick probes from within a zone, they will only fire if that zone happens to be running on the CPU on which the tick probe fires. This breaks many scripts that (naturally) use tick probes as a kind of local timeout mechanism. For us at Joyent, this has become a top annoyance for our customers who themselves want to use DTrace from within the zone, so we wanted to take a swing at addressing this -- but we also needed to be mindful (obviously) of not allowing privilege escalation. Complicating things, I also wanted to do this in a way that preserves the existing behavior for the profile probes: that they don't fire when in a context that one cannot execute is actually the easiest way of assuring that a profile-based enabling in the non-global zone does (roughly) what the user thinks it does. So the model we came to is to split the behavior (slightly) of the profile provider, and use the provider's dtps_usermode (which I have renamed to dtps_mode) to inform as to both mode (kernel mode v. user mode) and policy (if the user cannot execute in this context, this firing should be dropped v. restricted). When restricted, the user does not have either proc privileges, nor the privileges necessary to examine arguments, and attempts to do so will induce a UPRIV or KPRIV fault (respectively). From the (new) block comment explaining the dtps_mode entry point, the return value from dpts_mode is:
A bitwise OR that encapsulates both the mode (either DTRACE_MODE_KERNEL or DTRACE_MODE_USER) and the policy when the privilege of the enabling is insufficient for that mode (either DTRACE_MODE_NOPRIV_DROP or DTRACE_MODE_NOPRIV_RESTRICT). If the policy is DTRACE_MODE_NOPRIV_DROP, insufficient privilege will result in the probe firing being silently ignored for the enabling; if the policy is DTRACE_NODE_NOPRIV_RESTRICT, insufficient privilege will not prevent probe processing for the enabling, but restrictions will be in place that induce a UPRIV fault upon attempt to examine probe arguments or current process state. Attached is a patch that implements this. I have integrated this into our bits at Joyent (internal ticket is OS-431, "dtrace profile and tick probes sometimes don't fire in a zone"), so -- as with our other work -- you'll see this show up soon (next two weeks or so) at http://github.com/joyent/illumos-joyent, but I wanted to give folks an earlier heads-up in case we want to have further discussion here. In particular: Adam, it would be great if you could take a look at this at some point -- though I would obviously welcome anyone else's feedback as well! - Bryan
dtrace-tick.patch
Description: Binary data
_______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
