[libvirt] (resend) Problems with virt-manager checking access on virtual images.

Daniel J Walsh dwalsh at redhat.com
Fri Jan 30 12:38:40 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Met with Cole this morning and we talked about how SELinux can cause
people headaches when installing virtual images from random locations.

User downloads a iso image to his home directory and then uses
virt-manager to install it.  Problem is when the user has the whole
thing configured, virt-manager tells libvirt to install.  It executes
qemu and SELinux prevents qemu from reading the iso image because it is
labeled user_home_t and qemu is not allowed to read the contents of the
home directory.  qemu blows up with permission denied and the user is at
a loss to what just happened.

As we talked we realised this is not just an SELinux problem, but would
also happen if a use had an nfs homedir or potentially a samba home
directory where root was not allowed access.  Also pam_namespace would
cause problems, in the /tmp or /home/dwalsh would not be the same for
root as they are for the user.

One solution to the SELinux problem is to have a label that virt-manager
could apply to the iso image (virt_content_ro_t).  This would allow qemu
to access the file as long as it had search access to the path to the
image.  solving most of these problems.  But the user could still have
an access problem that would be tough to diagnose.  We came up with the
idea of a running a simple helper application to check read access to
the image file.  During the install, virt-manager could tell libvirt to
verify access by executing "qemuaccess /home/dwalsh/windows.iso".  If
this executable was labeled qemu_exec_t like the other qemu images the
same SELinux transitions would happen and we could instantly figure out
if SELinux was going to cause problems.  As a side benefit we could also
check if NFS or samba would cause a problems.  If qemuaccess failed,
virt-manager could put up a diagnostic message suggesting SELinux, NFS,
or Samba might be a problem, and the user could move the iso image to
some directory like /var/lib/libvirt/isos/, where libirt would have access.

I have attached a version that could solve the problem.

Comments?

Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmC9NAACgkQrlYvE4MpobO8egCgpOlWtlSSrC+TPK41fWC9YPWg
xwoAn2zYpk5ODoGhl5PXnwkltBKVjO1m
=PYqR
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemuaccess.c
Type: text/x-csrc
Size: 441 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090130/4beb7eed/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemuaccess.c.sig
Type: application/octet-stream
Size: 72 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090130/4beb7eed/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemuaccess.c.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090130/4beb7eed/attachment-0002.sig>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qemuaccess.c.sig.sig
Type: application/pgp-signature
Size: 72 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090130/4beb7eed/attachment-0003.sig>


More information about the libvir-list mailing list