On 2009.07.29 11:31:14 -0700, Steve Lawrence wrote:
> On Wed, Jul 29, 2009 at 08:43:05AM +0200, Martin Rehak wrote:
> > Hi Steve,
> > 
> > On 2009.07.23 14:34:22 -0700, Steve Lawrence wrote:
> > > On Thu, Jul 23, 2009 at 09:14:55AM +0200, Martin Rehak wrote:
> > > > Hi Steve,
> > > > 
> > > > On 2009.07.22 12:32:01 -0700, Steve Lawrence wrote:
> > > > > The issue is that from the global zone context (non-zlogin), stuff 
> > > > > like
> > > > > symbolic links to something like /etc could copy files from the global
> > > > > zone.
> > > > 
> > > > I don't understand it. cpio preserves symlinks, so symlinks will appear
> > > > just like symlinks in NGZ and files as a files. That means no mapping/no
> > > > risk. Am I right?
> > > > 
> > > > > I'm not sure why this is dangerous in this case, as we are only 
> > > > > reading
> > > > > from the zone, as cpio does not traverse/open sym links, it just 
> > > > > copes the
> > > > > link itself.
> > > 
> > > I don't see a problem with it, but you should get feedback from others as 
> > > well.
> > > I see a problem with the current implementation.  A spoofed cpio program 
> > > in
> > > an evil non-global zone could create a desctructive cpio stream.  The
> > > cpio -icdmP@ in the global zone could write to /.
> > > 
> > > Another solution could be to do the restore within the context of the
> > > zlogin, to a path mounted within the zone's root.
> > 
> > I see.
> > 
> > Is there any reason why we are doing a zone copy in the zlogin at all?
> > Which problems would we face if we copy a zone from global zone. That
> > would eliminate problems with evil zone environment completely.
> 
> I don't see one, but check with the install team.

That's what I am trying from the beginning. Do you have any particular
names or any alias in your mind, please.

>  I'm also not sure what
> is being copied here.  Is this clause to copy the "/" filesystem inside
> a zone, or just those added via "add fs".  If the latter, I'm not sure why

Exactly, just filesystems configured by 'add fs'.

> they are being copied.  Does LU treat any of the zone's filesystems as
> "shared between BE's", similar to how it treats /export/home in the global
> zone?

I think there should be the same rules as for the GZ. Not every time that code
need to copy the whole filesystem, just bits which were decided to be
unshared.

M.

> -Steve L.
> 
> > 
> > Many thanks
> > -- 
> > Martin
> > 
> > > -Steve L.
> > > 
> > > > 
> > > > That's what I think.
> > > > 
> > > > > Does this all end up going through zlogin one byte at a time?
> > > > 
> > > > Yes, the whole stream goes through zlogin from NGZ to GZ where it is
> > > > expanded.
> > > > 
> > > > What would be the problem if we wouldn't use any zlogin? Just a cpio on
> > > > zone root to a cpio to other zone root? What is the risk there?
> > > > 
> > > > Thank you
> > > > -- 
> > > > Martin
> > > > 
> > > > > -Steve
> > > > > 
> > > > > On Wed, Jul 22, 2009 at 04:57:47PM +0200, Martin Rehak wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > I am trying to get Live Upgrade better by reimplementing some parts 
> > > > > > of
> > > > > > the code. What I am not sure of is whether is it safe to do a copy 
> > > > > > of
> > > > > > non global zone imports (filesystems dedicated to a zone in its 
> > > > > > config)
> > > > > > from the global zone.
> > > > > > 
> > > > > > This is existing code (lucopy.sh:1808, install-nv-clone):
> > > > > > http://grok.czech.sun.com:8080/source/xref/install-nv-clone/usr/src/cmd/inst/liveupgrade/scripts/lucopy.sh
> > > > > > 
> > > > > > 1808        (
> > > > > > 1809            fgrep -xv $mountpoint /tmp/lucopy.zonefs.$$
> > > > > > 1810            cat /tmp/lucopy.zoneipd.$$
> > > > > > 1811        ) | sed 's+.*+^&/+' |
> > > > > > 1812        zlogin $ozonename \
> > > > > > 1813            "cat > /tmp/lucopy.excl.$$; \
> > > > > > 1814            (
> > > > > > 1815                if [ -s /tmp/lucopy.excl.$$ ]; then
> > > > > > 1816                    cd $zroot$mountpoint && \
> > > > > > 1817                    find . -depth -print | \
> > > > > > 1818                    egrep -vf /tmp/lucopy.excl.$$ | \
> > > > > > 1819                        cpio -ocmP@
> > > > > > 1820                else
> > > > > > 1821                    cd $zroot$mountpoint && \
> > > > > > 1822                      find . -depth -print | cpio -ocmP@
> > > > > > 1823                fi
> > > > > > 1824            )" |
> > > > > > 1825        ( cd $tdir && cpio -icdmP@ )
> > > > > > 1826        lulib_unmount_pathname $tdir
> > > > > > 
> > > > > > To describe it, I would say that it will zlogin into the non global
> > > > > > zone, generates there a listing which it sends onto stdin of cpio 
> > > > > > which
> > > > > > writes an archive on its stdout. That archive is directed to the
> > > > > > stdin of cpio running _OUTSIDE_ the zone (in the global zone) which
> > > > > > finally expands it and writes it to a target directory.
> > > > > > 
> > > > > > Unfortunatelly few lines above there is this comment:
> > > > > > 
> > > > > > 1769        # Mount each non-lofs zone import in a temporary 
> > > > > > location
> > > > > > 1770        # and copy over the bits that belong there, extracted 
> > > > > > from
> > > > > > 1771        # the running zone.  We are now reaching through zone-
> > > > > > 1772        # controlled paths and thus must be extremely careful.
> > > > > > 1773        # Direct copies are not safe.
> > > > > > 
> > > > > > And the question is: What can happen if I simply will not generate 
> > > > > > the
> > > > > > listing and the archive inside the zone but will do it in the global
> > > > > > zone and using 'cpio -p'?
> > > > > > 
> > > > > > If I generalize the problem a little bit more I would like to know 
> > > > > > your
> > > > > > opinion about my idea of copying whole BE including zones in just 
> > > > > > one
> > > > > > 'cpio -p'. Why it wouldn't work, please?
> > > > > > 
> > > > > > Thank you very much for your any reply
> > > > > > -- 
> > > > > > Martin Rehak
> > > > > > _______________________________________________
> > > > > > zones-discuss mailing list
> > > > > > zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to