On Tue, Sep 25, 2007 at 11:26:18AM -0400, Sebastien Roy wrote:
> Hi Dan,
> Dan Price wrote:
> > On Wed 19 Sep 2007 at 06:05PM, Sebastien Roy wrote:
> >> I'm working on adding a new service which runs in a non-global zone, and
> >> which uses a control device in /dev. How do I arrange for this /dev node
> >> to appear in non-global zones?
> > Check out /usr/lib/brand/native/platform.xml, which defines which
> > devices should appear in native brand non-global zones.
> Thanks for the pointer.
> > You should also think about which privileges your device needs, and
> > whether zones have those privs (or don't, as appropriate). Any pseudo
> > device going into a zone should also get a very thorough security
> > evaluation.
> > We can help-- feel free to follow up here, or offline.
> Thanks! I'm currently entertaining two different possible design options
> for this daemon. The first is as mentioned above; having a separate
> daemon in the non-global zone which accesses a common kernel control
> module. The second is having a single daemon living in the global zone
> and having the library used to access the daemon's interfaces access the
> global daemon from non-global zones using a door. Are there examples of
> the latter approach in other ON services?
well, there used to be in s10. they have been removed in snv.
looking at the approaches you're considering, the important question
that comes to my mind is where will the persistant data for this daemon
be stored, ie, how does this daemon handle re-starting. also, where do you
want your security boundaries?
if your daemon runs within the zone then your kernel driver can't trust
it. if it run in the global zone then you can.
if the daemon is restarted (either in the global zone or in the local
zone) it must be able to restore it's state. so that either needs to
be stored in the kernel driver, in the zone, or somehwere else.
zones-discuss mailing list