Re: [zones-discuss] Zone copy in Live Upgrade
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( > > > > > > 1809fgrep -xv $mountpoint /tmp/lucopy.zonefs.$$ > > > > > > 1810cat /tmp/lucopy.zoneipd.$$ > > > > > > 1811) | sed 's+.*+^&/+' | > > > > > > 1812zlogin $ozonename \ > > > > > > 1813"cat > /tmp/lucopy.excl.$$; \ > > > > > > 1814( > > > > > > 1815if [ -s /tmp/lucopy.excl.$$ ]; then > > > > > > 1816cd $zroot$mountpoint && \ > > > > > > 1817find . -depth -print | \ > > > > > > 1818egrep -vf /tmp/lucopy.excl.$$ | \ > > > > > > 1819cpio -ocmP@ > > > > > > 1820else > > > > > > 1821cd $zroot$mountpoint && \ > > > > > > 1822 find . -depth -print | cpio -ocmP@ > > > > > > 1823fi > > > > > > 1824)" | > > > > > > 1825( cd $tdir && cpio -icdmP@ ) > > > > > > 1826lulib_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. > > > > > > > > > > > > U
Re: [zones-discuss] Zone copy in Live Upgrade
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. 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 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? -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 && \ > > > > > 1822find . -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 inclu
Re: [zones-discuss] Zone copy in Live Upgrade
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. 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( > > > > 1809fgrep -xv $mountpoint /tmp/lucopy.zonefs.$$ > > > > 1810cat /tmp/lucopy.zoneipd.$$ > > > > 1811) | sed 's+.*+^&/+' | > > > > 1812zlogin $ozonename \ > > > > 1813"cat > /tmp/lucopy.excl.$$; \ > > > > 1814( > > > > 1815if [ -s /tmp/lucopy.excl.$$ ]; then > > > > 1816cd $zroot$mountpoint && \ > > > > 1817find . -depth -print | \ > > > > 1818egrep -vf /tmp/lucopy.excl.$$ | \ > > > > 1819cpio -ocmP@ > > > > 1820else > > > > 1821cd $zroot$mountpoint && \ > > > > 1822 find . -depth -print | cpio -ocmP@ > > > > 1823fi > > > > 1824)" | > > > > 1825( cd $tdir && cpio -icdmP@ ) > > > > 1826lulib_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
Re: [zones-discuss] Zone copy in Live Upgrade
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 && \ > > > 1822find . -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
Re: [zones-discuss] Zone copy in Live Upgrade
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. 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( > > 1809fgrep -xv $mountpoint /tmp/lucopy.zonefs.$$ > > 1810cat /tmp/lucopy.zoneipd.$$ > > 1811) | sed 's+.*+^&/+' | > > 1812zlogin $ozonename \ > > 1813"cat > /tmp/lucopy.excl.$$; \ > > 1814( > > 1815if [ -s /tmp/lucopy.excl.$$ ]; then > > 1816cd $zroot$mountpoint && \ > > 1817find . -depth -print | \ > > 1818egrep -vf /tmp/lucopy.excl.$$ | \ > > 1819cpio -ocmP@ > > 1820else > > 1821cd $zroot$mountpoint && \ > > 1822 find . -depth -print | cpio -ocmP@ > > 1823fi > > 1824)" | > > 1825( cd $tdir && cpio -icdmP@ ) > > 1826lulib_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
Re: [zones-discuss] Zone copy in Live Upgrade
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'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. Does this all end up going through zlogin one byte at a time? -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 && \ > 1822find . -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
