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