I trimmed most of the original email.

Jeff Victor wrote:
This is probably out of scope for this project, but "software delivery via zones" creates a potential security risk: software delivered via this method could have a limitpriv setting which is inappropriate in certain environments.

"Zone migration best practices" should include "after 'zoneadm -z ... attach', review the limitpriv setting with 'zonecfg -z ... info'". Should we also warn the user who just attached a zone that has a non-default limitpriv setting?

A different approach would be a mechanism to inspect the SUNWdetached.xml file and list its zonecfg-related contents *before* performing the attach. This would satisfy those organizations which are concerned by the possible omission of the "review zone's limitpriv" step.

Should either of those be include in a separate CR?

Yes, this seems orthogonal to my current proposal so we should just
handle this idea with a seperate RFE.

Instead what we want to do is similar to what happens when a zone is initially installed. The spooled pkg data and global zone files are the source for installing the zone. In this way the zone is installed with the correct pkg versions along with any patches that have been applied to those

Just looking for a clarification: if the intent is for the resultant zone to have the same set of pkgs as a newly created zone, will this method add any pkgs which:
1) do not exist in the detached zone
2) would be in newly created zones

I will rewrite this paragraph to try to be clearer.  I do intend
to sync up when there are missing dependent pkgs.  It will not be
just for the exact same pkgs as were originally there.  I was trying
to capture the key point that I don't want to "dowgrade" the zone and
I don't want to allow this update if the new host is in a "mixed state"
as compared to the original host.

zones-discuss mailing list

Reply via email to