Hi Jonathan,
> 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
> %
> ).
"ppriv $$" in the global zone gives me
14567: -bash
flags = <none>
E: basic,dtrace_proc,dtrace_user,file_dac_read,proc_owner,proc_zone
I: basic,dtrace_proc,dtrace_user,file_dac_read,proc_owner,proc_zone
P: basic,dtrace_proc,dtrace_user,file_dac_read,proc_owner,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.
My UID is the same in the global and in the local zone.
> 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.
After some initial confusion Jon Haslam found out that the reason for the
absence of DTrace's cross-zone-ability is just the too old 11/06 release we're
using.
Thomas
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]
