[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-code
Subject:    Re: [osol-code] Masking KStats visable to Non-Global Zones
From:       Peter Memishian <peter.memishian () sun ! com>
Date:       2007-10-02 16:17:47
Message-ID: 18178.28459.995381.332710 () dhcp-cbjs05-219-56 ! PRC ! Sun ! COM
[Download RAW message or body]


 > 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
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
[prev in list] [next in list] [prev in thread] [next in thread]