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
"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
correct pkg versions along with any patches that have been applied to
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