Edward Pilatowicz wrote:
> On Wed, May 28, 2008 at 01:00:08PM -0600, Jerry Jelinek wrote:
>> Edward Pilatowicz wrote:
>>> hm.  from what i remember mount mode actually puts the zone root at
>>> <zoneroot>/a and lofs mounts stuff from the global zone at <zoneroot>,
>>> all so that the svr4 packaging code can "enter" the zone to do packaging
>>> operations.  i thought this dance was necessary because we wanted packaging
>>> scripts to execute inside a zone (since for security reasons, we wouldn
>>> t want them to be able to muck with stuff outside a zone).  but IPS doesn't
>>> have packaging scripts.  so will this complicated setup really be necessary
>>> for IPS?  ie, could we do away with the /a mount in mount mode for IPS?
>>> i'm asking about this because the /a mount code in zoneadmd has lots of hard
>>> coded paths and makes zoneadmd pretty complicated.  (just look at
>>> mount_filesystems() and build_mounted_post_var().)  i've had to modify this
>>> code a few times, i've broken it a couple times, and been confused by it all
>>> the time...
>> Ed,
>> Yes, this description is correct but not because of the pkging
>> code.  We want to be able to enter the zone while running the
>> sw that is installed in the global zone, irrespective of what is
>> inside the non-global zone.  All of the global zone sw is mounted
>> read-only in a mounted zone so we can login into the zone and
>> have a safe environment that matches the global zone.  The non-global
>> zone is mounted under /a so we can safely operate on it within the zone
>> using the global zones sw.  None of this has any relationship to
>> the pkging code in either zone.  All the mount is doing is setting
>> up a safe zone that is compatible with the global zone.  With this
>> definition, you can use mount to safely do any kind of admin work,
>> not just running pkging code.  The problem with the current mount
>> is it lofs mounts the zone's etc and var back into the global zone
>> mount area.  This obviously won't work for non-native zones or even
>> older zones that we are migrating to the new host, which is why I
>> had to fix this for update on attach.
> ah.  ok.  thanks for clearing that up for me.  i assume all that stuff
> was for zulu/lu and we would be able to rip it out someday...


It was originally added for zulu but I think this is generally useful
and we wouldn't want to remove it, but just make it work for all brand
types.  For example, if you try to install an rpm from the gz into a lx
branded zone that has been previously booted (assuming that is possible),
then the same security issues exist as with svr4 pkgs.  I think we want
to maintain the idea that we have a safe way to do gz administration of
ngz's for all sorts of admin operations, not just pkging, and the mount
gives us that.


zones-discuss mailing list

Reply via email to