On Thu, Aug 28, 2008 at 12:27:34AM -0700, Thomas Mohme wrote:
> Hi Adam,
>
> I continue being interested in solving the problem - just was out of office
> yesterday.
>
>
> I get this strange behavior when (as non-root with dtrace-proc and
> dtrace-user privs) I try to trace a process in a non-global zone
> (running there under my account, same privs) from the global zone.
>
>
> This already is my "fallback" path, because my first attempt (to do
> the tracing in the non-global zone where the process is running)
> failed with "dtrace: failed to initialize dtrace: DTrace device not
> available in local zone"
>
> I get the same effect with a variant of the classic "hello,
> world"-program when trying to trace it in the same manner (cross-zone,
> as described above).
>
> But everything works as expected when I'm running both the "hello,
> world"-program and dtrace in the global zone.
>
> Unfortunately running the server-process in the global-zone isn't a
> practicable path, because this process depends heavy on the versions
> of installed third-party libraries, which differ between the zones.
Do you have the "PRIV_PROC_ZONE" privilege? (you can check by running:
% ppriv $$
...
flags = <none>
E: basic,proc_zone
I: basic,proc_zone
P: basic,proc_zone
L: all
%
).
With zones, there's no guarantee that UIDs inside a local zone matches the UIDs
in the global zone. So the system prevents processes in the global zone from
effecting processes in local zones.
With this privilege on your global zone process, you'll be able to act on
processes in other zones with your UID just as if they were in the global
zone. It grants no other rights.
The dtrace(1M) consumer needs to be able to attach to a process like a debugger
to set up some of it's probes. Without PRIV_PROC_ZONE, it's not possible
to do so.
Cheers,
- jonathan
_______________________________________________
dtrace-discuss mailing list
[email protected]
