> James Dickens blog entry today demonstrates one concerning bit of data
> visible to non-globalzones via kstats.
> http://uadmin.blogspot.com/2007/09/in-zone-but-where.html
>
> There are other stats that could fall in the same category both now or
> in the future. Which raises the question: is there a method by which
> to mask out kstats that are visible to non-globalzones? I noticed that
> the iscsi initiator nodename (IQN) isn't visable which makes me think
> there is already a way to mask or hide values, but digging through ON I
> couldn't figure out how.
I'm not entirely sure I understand the question, but I believe each kstat
should be tied to a zone when it is created (via kstat_create_zone()).
There's also the older (pre-zones) kstat_create() function which is a
wrapper around kstat_create_zone():
kstat_t *
kstat_create(const char *ks_module, int ks_instance, const char *ks_name,
const char *ks_class, uchar_t ks_type, uint_t ks_ndata, uchar_t ks_flags)
{
return (kstat_create_zone(ks_module, ks_instance, ks_name, ks_class,
ks_type, ks_ndata, ks_flags, ALL_ZONES));
}
So in other words, AFAIK the kstat framework is zone-aware and the
consumers should be able to control visibility by using
kstat_create_zone(). However, if they use kstat_create() (as most do),
then the kstats will be visible to all zones.
--
meem
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
