-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel P. Berrange wrote: > On Fri, Jan 30, 2009 at 09:06:38AM -0500, Daniel J Walsh wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Daniel P. Berrange wrote: >>> I don't particularly like the idea of running another program to check >>> this because SELinux context isn't the only thing which will potentially >>> prevent QEMU accessing the disk image. CGroups device policy make prevent >>> it. A setuid() call in QEMU to drop privileges, may prevent it. It may >>> be asked to open it read-write, and only be able to open it read-only . >>> It may want to take a lock on the image, but it already be locked, and >>> so on. QEMU does already report pretty much the same error message as >>> the qemuaccess program does when it is unable to access a disk image >>> >>> # virsh start demo >>> libvir: QEMU error : internal error unable to start guest: qemu: could not open disk image /home/berrange/Fedora-9-i686-Live.iso >>> >>> IMHO, this all stems from a mistake I made when designing the original >>> virt-manager UI. Namely, I should never have used a generic file >>> dialog which allows selection of disk images anywhere on the host. It >>> was wrong for general disk images, in just the same way that its wrong >>> for ISO images. And absolutely useless for remote provisioning. >>> >>> With the storage pool APIs we have the opportunity to fix this in a way >>> helps not only the SELinux case, but also the app in general. Instead of >>> showing a generic file dialog, we should just show a dialog displaying >>> the configured storage pools, and allow the user to pick an ISO out of >>> one of the the pools. virt-manager should offer to remember which storage >>> pool contains installable ISO images, and which should be used by default >>> for disk images. We already have /var/lib/libvirt/images by default for >>> disk images, and should add /var/lib/libvirt/isos too. If a user downloads >>> an ISO to their home directory, we could easily have a option in the UI >>> for 'Import an ISO file to the pool' which would move it into the correct >>> location. >>> >>> NB, here I am talking about use of the system-wide QEMU driver instance >>> of 'qemu:///system', which runs privileged on the host. This is really >>> intended at server deployments of virt, but we have been happening to >>> use it for general ad-hoc desktop usage too in Fedora. >>> >>> There is also a per-user 'qemu://session' UI where both libvirtd and the >>> QEMU guests run unprivileged as that user's UID. In that scenario the >>> storage pools should use something like $HOME/VirtualMachines/images and >>> "$HOME/VirtualMachines/ISOs'as the default pools for disk & ISOs >>> respectively. I would like to see Fedora use qemu:///session by default >>> for generic desktop virt usage, in which case everything runs as that >>> UID, and keeps everything in $HOME. >>> >> We discussed this also. The only problem I see here is the additional >> disk usage, since you would permanently keeping the iso, even though you >> might only be using it once. What about removable media, cdrom and usb >> key isos. Do you want to copy them to the /var/lib/libvirt/isos >> directory also? > > If think if someone downloads a large ISO its fairly likely they'll want > to keep it around for some amount of time, rather than risk having to > download it again. That said, our storage pools APIs can trivally be > used to delete it if it is no longer required. > > For removable media, we're just directly attaching the block device, > so we can't avoid the need to re-label from fixed_dev_t (or equiva) > to virt_image_t - though having a virt_image_ro_t for readonly access > would be preferrable for cases where we're explicitly attaching it to > the guest in read-only mode. > > USB keys I'm not so sure about - in the common case they'll be FAT > filesystem which doesn't support labelling at all. So we'd either have > to ensure its mounted with a suitable context= mount option, or get > the policy to to allow read-only access to the default mount context > for FAT filesystems. The /var/lib/libvirt/isos directly is just a > plain directory based storage pool. We also have concept of filesystem > based storage pools (eg a local device, mounted in some directory) > which can we directly manage. Likewise NFS mounts we can handle > directly, mounting a remote directoy from a server in a specific > place, so we can ensure a context= mount option is used. > > So I think a combination of factors > > - Default directories for local host stored file based images & ISO > which get correct context automatically > - libvirt has to set contenxt on any block device nodes which need > to be assigned > - Setting mount context for removable disks / changing policy to > allow read-only access to mounted removable disks. > > >> Are the isos in this directory going to be Read Only or can some qemus >> read/write them? > > Any files used to back the QEMU CDROM device should be restricted to > be read-only, since we need ability to safely assign the same ISO to > multiple guests concurrently - for concurrent installs. So a new disk > type virt_image_ro_t might be desirable here. > > Daniel New file context in /var/lib/libvirt/images(/.*)? gen_context(system_u:object_r:virt_image_t,s0) /var/lib/libvirt/isos(/.*)? gen_context(system_u:object_r:virt_content_t,s0) HOME_DIR/VirtualMachines(/.*)? gen_context(system_u:object_r:virt_image_t,s0) HOME_DIR/VirtualMachines/isos(/.*)? gen_context(system_u:object_r:virt_content_t,s0) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkmDGvQACgkQrlYvE4MpobNqnwCfXvE6ZrPZ05igprlDxCNOXc24 c84AoIjZKuCdczTj2p29l1+zV3ze1Q/6 =pin6 -----END PGP SIGNATURE----- -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list