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. -Seb _______________________________________________ zones-discuss mailing list firstname.lastname@example.org