Edward Pilatowicz wrote:
> well, there used to be in s10.  they have been removed in snv.

Thanks for the reply.  Was the general approach then to have a process in 
the non-global zone grab a door descriptor from the kernel somehow?  How 
did the daemon in the global zone know where a particular door request 
was coming from (i.e., which zone)?  It would be great to be able to go 
look at this prior implementation.  What was it?

> 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.

The daemon is started from an SMF service.  Its data will ultimately be 
stored in the SMF repository, but is currently in a file in /etc.

> also, where do you want your security boundaries?

The boundaries are zone boundaries, and I would think that it would be 
doable for either the kernel to enforce those boundaries (in the case 
where a daemon runs from the non-global zone) or the daemon in the global 
zone (in the case where user processes are using an API to call in to the 
global-zone daemon.)

> 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.

Hmm, I'm not sure what you mean by "can't trust it".  The kernel can 
restrict what operations are allowed based on privileges associated with 
a restricted set of safe operations.  The kernel could trust the daemon 
to perform those operations even from a non-global zone if given those 
privileges, right?

> 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.

Right, that part seems straightforward to me, as the service in question 
is already implemented to run in the global zone.  Those questions have 
already been resolved for the global zone, and should map fairly well to 
a non-global zone service if we decide to do that.  It's not at all clear 
that I want the daemon to run in non-global zones, however, due to object 
namespace management issues which would be more easily handled from a 
single daemon in the global zone.  This latter point is what is driving 
the design decision toward a single daemon in the global zone.

zones-discuss mailing list

Reply via email to