Hello,
Has anyone run into this situation before? Is there a way to do this?
Please respond directly to me since I''m not on this alias.
Thanks!
Jodi Edwards
We are not trying to run DTrace on a local zone as we are already aware
it is not possible. Our intent is to monitor the local zones using
DTrace on the GLOBAL. Ideally we would like to use the PID flag on
DTrace, however it seems to either require root access or additional
permissions that we do not have enabled. It also seems like a user on
the GLOBAL zone can not attach to LOCAL zone processes even though the
UID:GID pair is identical.
A detailed trace is listed below. I suspect we''re encountering a
challenge with Zone-based security credentials (DTrace being just a
symptom).
======================================================================================================================================================
Our problem is as follows:
Application processes are started as user ''xyz'' on the LOCAL
zone
(uid=2394 gid=2001)
User ''xyz'' logs into the GLOBAL zone using their credentials
which match
those of the local zone (suid=2394 gid=2001)
User ''xyz'' is unable to attach to a specific process using the
DTrace
''-p'' option.
Example of entire test (processes already running in the local zone):
EXECUTED ON GLOBAL ZONE (AS USER)
#dtrace -p 2621 -l
dtrace: failed to grab pid 2621: permission denied
$ ppriv -v $$
15911: sh -i
flags = <none>
E:
dtrace_kernel,dtrace_proc,dtrace_user,file_link_any,proc_exec,proc_fork,proc_info,proc_session
I:
dtrace_kernel,dtrace_proc,dtrace_user,file_link_any,proc_exec,proc_fork,proc_info,proc_session
P:
dtrace_kernel,dtrace_proc,dtrace_user,file_link_any,proc_exec,proc_fork,proc_info,proc_session
L:
contract_event,contract_observer,cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,file_chown,file_chown_self,file_dac_execute,file_dac_read,file_dac_searc
h,file_dac_write,file_link_any,file_owner,file_setid,ipc_dac_read,ipc_dac_write,ipc_owner,net_icmpaccess,net_privaddr,net_rawaccess,proc_audit,proc_chr
oot,proc_clock_highres,proc_exec,proc_fork,proc_info,proc_lock_memory,proc_owner,proc_priocntl,proc_session,proc_setid,proc_taskid,proc_zone,sys_acct,s
ys_admin,sys_audit,sys_config,sys_devices,sys_ipc_config,sys_linkdir,sys_mount,sys_net_config,sys_nfs,sys_res_config,sys_resource,sys_suser_compat,sys_
time
$ pcred $$
15796: e/r/suid=2394 e/r/sgid=2001
$ pcred 2621 <----- Validation that a user residing in the GLOBAL
zone is unable to attach to a LOCAL ZONE PID (without
invoking DTrace).
pcred: cannot examine 2621: permission denied
$ dtrace -n ''syscall:::{@[zonename]=count()}''
<----- Validation
that user ''xyz'' is able to use the zonename variable to
monitor probes
dtrace: description ''syscall:::'' matched 458 probes
^C
drbc01a 68
drmdcas01 71
drmdgc01a 74
drgc02a 81
drfe01 94
drgc01a 97
drfix01 108
drmdgc02a 116
global 2960
sbtbc5a 15194
EXECUTED ON GLOBAL ZONE (AS ROOT) -- PROCESS ''2621'' resides
in the
LOCAL ZONE [THIS WAS SIMPLY TO CHECK THE CREDENTIALS OF PROCESS
''2621'']
root at sbtbc99a:/>
# pcred 2621
2621: e/r/suid=2394 e/r/sgid=2001
--
______
/_____/\ Jodi Edwards
/_____\\ \ Kernel Support Engineer
/_____\ \\ / Enterprise Services
/_____/ \/ / /
/_____/ / \//\ Sun Microsystems Inc.
\_____\//\ / / 500 Eldorado Blvd
\_____/ / /\ / Broomfield, CO 80021
\_____/ \\ \ Phone: 303-272-6587
\_____\ \\ Email: jodi.edwards at sun.com
\_____\/
"Submit, check and update tickets at
http://www.sun.com/service/online"
> We are not trying to run DTrace on a local zone as we are already aware it is > not possible. Our intent is to monitor the local zones using DTrace on the > GLOBAL. Ideally we would like to use the PID flag on DTrace, however it seems > to either require root access or additional permissions that we do not have > enabled. It also seems like a user on the GLOBAL zone can not attach to LOCAL > zone processes even though the UID:GID pair is identical.The problem is that though the user has been given the privilege "dtrace_proc", he/she lacks the "proc_zone" privilege which allows unprivileged users in the global zone access to the processes with a matching userid in a non-global zone. Although I haven''t tested it, you should be able to add the "proc_zone" to whatever role was setup for DTrace and then the user should be able to use the PID provider. dsc
On Fri, Aug 26, 2005 at 01:41:51PM -0600, Jodi Edwards wrote:> Hello, > > Has anyone run into this situation before? Is there a way to do this? > Please respond directly to me since I''m not on this alias. > > Thanks! > > Jodi Edwards > > > > We are not trying to run DTrace on a local zone as we are already aware > it is not possible. Our intent is to monitor the local zones using > DTrace on the GLOBAL. Ideally we would like to use the PID flag on > DTrace, however it seems to either require root access or additional > permissions that we do not have enabled. It also seems like a user on > the GLOBAL zone can not attach to LOCAL zone processes even though the > UID:GID pair is identical. > > A detailed trace is listed below. I suspect we''re encountering a > challenge with Zone-based security credentials (DTrace being just a > symptom).In order to effect processes in other zones from the global zone, you need the proc_zone privilege: % ppriv -vl proc_zone proc_zone Allows a process to trace or send signals to processes in other zones. % With just proc_zone+dtrace_proc, you can create pid* probes on processes with the same uid in other zones. To effect processes with different UID/GIDs, you also need proc_owner: % ppriv -vl proc_owner proc_owner Allows a process to send signals to other processes, inspect and modify process state to other processes regardless of ownership. When modifying another process, additional restrictions apply: the effective privilege set of the attaching process must be a superset of the target process'' effective, permitted and inheritable sets; the limit set must be a superset of the target''s limit set; if the target process has any uid set to 0 all privilege must be asserted unless the effective uid is 0. Allows a process to bind arbitrary processes to CPUs. % Does that resolve all of your issues? Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development