on 2014/06/06 02:33, Paul Clarke wrote:
On 06/05/2014 03:36 AM, Zhou Zheng Sheng wrote:
>>> It seems difficult to make a new ISO available, or I chose a poor way.
>>> - I downloaded from an FTP site requiring non-anonymous authentication
>>> - I scp'd it to root@host
>>> - I tried to use it from there, but I got permission denied
>>> "KCHISO0008E: The
>>> hypervisor doesn't have permission to use this ISO /root/..."
>>> - the message above recommends copying the file to /var/lib/libvirt,
>>> but I
>>> think you actually have to copy it to /var/lib/libvirt/images
>>> - you also need to "chown qemu" the ISO image
>>> After the above steps, it finally became visible and usable.
>> For current kimchi security model design,
>> root users on behalf of console administrator, they are responsible for
>> 1. host setup for virtualization infrastructure and console
>> 2. virtualization resources setup
>> I think this process should be streamlined for better user experience.
>> I recommend to make "chown qemu" transparent with kimchi to handle it
> The user also has to add "x" for QEMU on each level of the directory
> that contains the ISO image. Though this can be done by Kimchi
> automatically, it's possible that the user accidentally revokes the
> from the directory and change the owner of the ISO image. The problem
> here is that the downloaded ISO is out of backend management.
> In this case, Kimchi is used as a desktop virtualization management
> soft. Libvirt already provides a "session" mode to solve desktop
> virtualization privilege problem. We can have the Kimchi backend create
> the VM in "session" mode, so that the VM gets the same privilege as the
> user, and it's able to read the ISO image.
> Another solution is that we provide an ISO upload interface to allow
> user to upload the image from his home directory to Kimchi backend. Then
> Kimchi store the image in /var/lib/libvirt/images and take over the
> control. This solution keeps Kimchi in the server virtualization way,
> which is its original orientation, to compete with XXWare server.
This may be complicated by limitations of HTTP. There may be some sort
of maximum size permitted which is at or below the typical size of an
Linux installation ISO image. I'm not knowledgeable in that area, but
I've seen issues like that.
In vanilla HTTP 1.1 protocol there is no limitation. Usually the
limitation is forced by the browser, web server or the application
framework. This technical issue can be solved in many ways. The problem
I think is that malicious users can perform DoS attack to cause the
server runs out of space. If we are to go this way, maybe we have to add
some constrains, and only allow the root user to upload ISO files.
Kimchi-devel mailing list