OpenSolaris

Printable Version Enter a New Search
Bug ID 6388070
Synopsis non-root non-global zone users can't get dtrace provider modules to load
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:dtrace
Keywords onnv_triage | zones
Responsible Engineer Daniel Price
Reported Against
Duplicate Of
Introduced In
Commit to Fix snv_37
Fixed In snv_37
Release Fixed solaris_nevada(snv_37) , solaris_10u4(s10u4_03) (Bug ID:2144466)
Related Bugs 4970596
Submit Date 20-February-2006
Last Update Date 16-February-2007
Description
With Adam's help I tracked down some puzzling behavior I occasionally saw when
testing some zones/dtrace related changes.  The symptom was that sometimes,
as 'dp', I didn't see all of the probes I would expect to see.

We eventually tracked this down to:

  ...                                                                           
  open("/dev/dtrace/provider/systrace", O_RDONLY) Err#13 EACCES [file_dac_read] 
  open("/dev/dtrace/provider/fbt", O_RDONLY)      Err#13 EACCES [file_dac_read] 
  open("/dev/dtrace/provider/sdt", O_RDONLY)      Err#13 EACCES [file_dac_read] 
  ...  

Which happens because the permissions on these nodes is 600, instead of the
expected 644.  Normally this is harmless, but if the provider modules
(systrace, sdt, etc.) are not yet loaded on the system, then it appears that
they won't get loaded, and we'll fail to register those probes.

Happily the fix is simple-- we just need to add /etc/minor_perm entries for
the providers.
The other wrinkle, it turns out, seems to be devfs-- in the global zone the
mere act of examining /dev/dtrace/provider/<mumble> is enough to cause
the module to load (ls /devices/pseudo to see this in effect).  Since
non-global zones don't use devfs, but mknod'd nodes, they don't receive
this benefit, and so the permissions become more important.

So the scope of this is limited to non-global zones, and since dtrace
and non-global zones don't mix in S10, I'm removing that CR.

Another problem here seems to be that i.minorperm doesn't update
the permissions in non-global zones.  I'll investigate that further...
Work Around
manually change the permissions on the appropriate devices using chmod.
Comments
N/A