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 not. 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?). Nico -- _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
