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. -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
