On Mon, Dec 08, 2008 at 12:37:48PM -0500, James Carlson wrote:
> > I am not planning on making any automated changes to the privileges 
> > available
> > to the zone.  If this turns out to be an important issue, then we could
> > look at that as a possible future enhancement.  The problem I see is that
> > we don't have any data to automatically drive which services and apps need
> > which privs.
> Right; that's what I was getting at.  We don't carry that sort of
> metadata around in any convenient form.
> I suppose it'd be possible to look through the SMF 'privileges' for
> the services that are still enabled, and then attempt to union those
> into the zone privileges ... but it's unclear if that's really the
> right approach, particularly for services that might be aware enough
> of zones to work in some other fashion when restricted by the
> environment.

Shouldn't changes to privileges be backwards compatible?  I can't quite
tell if privilege names and semantics are intended to be Committed or

In any case, even if privilege names and semantics not stable, surely
services can discover incompatible changes (e.g., if a service's
method_context refers to invalid privilege names then SMF can discover
this), and services that drop/retain specific privileges too will fail.
So at least the failures should be obvious.

No, I don't know how best to deal with such situations.

> There are other things that work like this, such as ZFS delegations or
> in network configuration, so there might be a broader issue here in
> configuring the zone so that it can properly accept the archive.  I'm
> not saying that I think it's unusable, but rather that there may be
> non-trivial cases here where a good bit is left to the user's
> imagination.

And if the image itself expects to have zones...  Yes, some things can
break, but maybe we should design the system so that using a system
image as a zone root should just work, with services that can't run in
NGZs disabling themselves, and services that can be configured
differently to run in zones either disabling themselves or changing
their configuration (as in your NL7C example, though why shouldn't NL7C
be available in NGZs?).

zones-discuss mailing list

Reply via email to