On 08/08/2012 02:35 AM, Michael Still wrote:
> On 08/08/12 11:08, Pádraig Brady wrote:
>
>> If supporting either of the above cases, it would be great to
>> reuse the existing image loopback mounting code:
>>
>> virt.disk.setup_container(image_file)
>> virt.disk.inject_file()
>> other tweaks
>> virt.disk.destroy_container(image_file)
>
> This code doesn't seem to support _reading_ from the container though.
> The current process (if you specify a glance image is):
>
> - fetch image from glance
> - mount it
> - inject the data into it
> - _copy_ the entire directory structure from the mounted image into the
> config disk image
>
> Its that final step that I think is hard with the containers code,
> unless I am missing something.
> What's the security vulnerability here? Its writing to something which
> might be a symlink to somewhere special, right?
That's one vector.
Even mounting the image is a potential vector.
Anyway these issues should be kept within virt.disk.api
(which can use libguestfs as it is).
> Would it be better for example to mount the image from glance, copy its
> contents to the config disk image (skipping symlinks), and then umount
> it? The data could then be written to the config disk instead of to the
> image from glance. That would mean if there was a symlink pointing
> somewhere special in the glance image it couldn't be exploited.
That would help, but as mentioned above, the loop mount itself
can be dangerous. So just using the disk.setup_container()
as mentioned above, will help, and at least avoid reimplementing
loop back mounting code.
Keeping symlinks could be a useful feature BTW.
Perhaps {cp,tar,rsync} --one-file-system could be
leveraged to merge trees in a more secure way.
cheers,
Pǽdraig.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
