Sorry about the late replay.<br><br>It's dangerous if a cracker gets the private key.<br>The image data is encrypted during the transportation. But after that,<br>a cracker can copy any image include the resized/migrated one on the<br>


dest compute node using the private key. And the dest node could be any<br>compute node. Under this situation encryption is not usefull. <br><br>By setting "write only = true" in rsyncd.conf, any attempted image<br>


downloads will fail. This protects images on the dest compute node<br>from getting downloaded. AFAIK, sshd can't do this. One of its<br>shortage is that images on the dest node can be overwritten by rsync<br>command. Using ssh has this shortage, too.<br>


<br>If "use chroot" is set "yes" in rsyncd.conf, the rsync daemon will<br>chroot to the instances path before starting the file transfer with<br>the client. This is usefull.<br><br><div class="gmail_extra">


<br><br><div class="gmail_quote">2012/11/2 Eric Windisch <span dir="ltr"><<a href="mailto:eric@cloudscaling.com" target="_blank">eric@cloudscaling.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px"><span><div><div><div><blockquote type="cite"><div><br>The disks are copied from source to destination via rysnc over ssh during resizing/migrating.<br>



It means that we will need a password-less ssh private key setup among all compute nodes.<br>
It is a security problem in some environment. This blueprint will use rsync itself(not over ssh) <br>to copy/delete the disks.<br></div></blockquote><div>Are you planning to improve rsync? I don't think its more secure to use rsync without ssh, with rsync over ssh, not only we have the authentication, but also the data encryption during the transportation.  password-less ssh may have potential risk, but still its more secure than rsync itself. </div>


</div></div></div></span></blockquote></div><div><div>I suspect his concern is less about the protocol, but about how it is used.  The code forces all disk migrations to happen as 'root' and presumes that the systems have password-less ssh keys configured between them.</div>


<div><br></div><div>While the rsync protocol would be less secure in and of itself, it is easily chrooted. It changes the attack surface. Instead of being able to compromise the dom0 from another (already) compromised dom0, you'll "only" able to compromise the guests from any host (as any user) that has access to rsync port.</div>


<div><br></div><div>There are ways to make rsync+ssh more secure than it is used currently, but this may just be the wrong solution, period.</div><div><br></div><div>Regards,</div><div>Eric Windisch</div>
                </div>
            <br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Best,<br><br>Jian<br><br>
</div>