[virt-tools-list] [PATCH] Don't create disk images world readable and executable

[Ron]

On Thu, Jul 03, 2014 at 09:40:59AM +0200, Martin Kletzander wrote:
> On Thu, Jul 03, 2014 at 12:41:57AM +0930, Ron wrote:
> >
> >So I guess I should paint a slightly fuller picture of everything
> >I was hoping to achieve here.
> >
> >I have disk images in a directory structure that looks like this:
> >
> >drwxrws--- 2 libvirt-qemu libvirt ... /srv/vm
> >-rw-r----- 1 libvirt-qemu libvirt ... /srv/vm/my.img
> >
> >This keeps them private from unprivileged users, lets QEMU use
> >them, and lets users in the libvirt group create them in that
> >directory and read them.
> >
> >The latter is important here because I've written a backup script
> >that lets users in group libvirt take a snapshot of the XML and
> >disk image(s), and which works "the same" on both running VMs and
> >on ones that are shut down.  If the VM is running it uses a QEMU
> >'drive-backup' transaction to get a coherent snapshot of the disk
> >without having to do the "snapshot/blockpull" dance.  And if it
> >is not, the image is simply rsynced to the backup location.  In
> >both cases the VM description is read with dumpxml.
> >
> >In the running VM case, QEMU does the work and is the image owner,
> >in the shut down case, the libvirt group gives rsync permission
> >to read it.
> >
> >And that all works great, except for one, now become two, little
> >catches ...
> >
> >The first was, that with dynamic_ownership, when the VM is shut
> >down, the ownership of the disk image changes to root:root, which
> >means users in group libvirt can no longer read them to back up.
> >I thought I'd solved that by turning dynamic_ownership off.
> >
> >What I missed until now, is that without dynamic_ownership, if
> >I try to create a new VM in that directory with virt-install,
> >it creates an image like this:
> >
> >-rw-r----- 1 ron libvirt ... new.img
> >
> >Which QEMU, running as libvirt-qemu:libvirt-qemu now doesn't have
> >permission to access, and the install fails immediately after the
> >disk image is created.
> >
> >Which I could fix by turning dynamic_ownership back on, except ...
> >Bugger.  :/
> >
> >If dynamic_ownership could restore it to ron:libvirt, then that
> >would work fine, and I wouldn't even need the sticky libvirt
> >group on that dir.   Maybe I'm missing something obvious that
> >will still give me an elegant solution here, but I'm not seeing
> >it yet ...   Hmmm.
> >
> >
> >What about if instead of trying to 'remember' it, we just allow
> >users to specify in the XML what ownership it should be returned
> >to when the VM is shut down?  The code for that should be simple,
> >is there some other use case that would fall down for?
> 
> Multiple domains with different definitions for example.
> 
> But getting to the thing, I'm not sure why you have different group
> for VMs using image files and users/scripts.  I, personally, would set
> the group either in qemu.conf for all machines ...

On Debian at least, libvirt is built with:
--with-qemu-{user,group}=libvirt-qemu, and 'libvirt' as the privileged
libvirt user group.  And 'ron' is the user I added to group libvirt
as an admin for the domains.  The VMs are all intended to run under the
system hypervisor instance with bridged networking.

So initially I've just been trying to make this work with those default
users and groups.  I know I can change the user/group in qemu.conf, but
that wouldn't really change the overall problem much for me.

> ... or as a dac seclabel in the XML definition.

This however was the big clue I was missing, thanks!  I think this will
in principle at least, let me do what I really needed here - including
the next thing on my todo list, which was finding a way to run the VMs
under the system hypervisor, but as separately contained users.

Except it doesn't quite seem to work ...  and I'm not certain yet if
that's just me making some mistake, or a bug, but it's looking a bit
like one or more bugs ...

> You can also disable re-labelling of particular disk images or files.

Do you mean with: <seclabel type='static' model='dac' relabel='no'>
or something else?

Since that doesn't appear to work if dynamic_ownership=1.  It still
changes owner on start up and shut down the same as if that option
wasn't there.  It's not clear to me yet which code path is being
followed for that to happen though.

If I set dynamic_ownership=0 though, then using relabel='yes' doesn't
work (which is another way I could otherwise get around the VM creation
time problem).  That seems to be because of code like this:

  if (!priv->dynamicOwnership)
     return 0;

  secdef = virDomainDefGetSecurityLabelDef(def, SECURITY_DAC_NAME);

  if (secdef && secdef->norelabel)
     return 0;

And it's not clear to me if that is really by design, or an oversight
when the fixes for dynamicOwnership=0 were made?

I would have thought the XML could always override the global setting?



The other thing that doesn't quite work here, is if I run virt-install
with something like: -n myvm --security type=static,label=ron:libvirt
then that solves my original case from above for the disk image, but
the install then fails because it's unable to create/access:
/var/lib/libvirt/qemu/myvm.monitor

Since /var/lib/libvirt/qemu is
drwxr-x--- 6 libvirt-qemu libvirt-qemu 4096 Jul  2 23:38 qemu

Am I missing something obvious there too, or do we need a way to
explicitly specify the monitor socket directory so that separate
users can each have their own that isn't accessible by the others?


But otherwise, this looks very close to exactly what I need here.


> The dynamic_ownership settings is intended for easy scenarios as it
> will not meet the expectations for most complex ones.

Ok, that makes sense.  I looked over the code for it to make sure
I wasn't missing something I needed before I turned it off, but the
documentation for it I found is a bit thin and I wasn't quite sure
of the intent.  Turning it off and using seclabel for each domain
seems like the right thing for what I want here.

  Ron