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

[Ron]

On Wed, Jul 02, 2014 at 01:50:27PM +0200, Martin Kletzander wrote:
> On Wed, Jul 02, 2014 at 07:36:00PM +0930, Ron wrote:
> 
> >That could probably be fixed by implementing the XXX in
> >security_dac.c: virSecurityDACRestoreSecurityFileLabel(), to
> >actually restore the real previous owner rather than just
> >blindly setting it to 0:0 (root:root).
> 
> Already being dealt with for a long time [1], the problem is it does
> have lots of caveats.  Even more when you want to satisfy all users
> (impossible).

Yeah, I briefly entertained patching that, and decided Doing It Right
would be Hard too ...  but then I thought I could get what I needed
in my case by just disabling dynamic_ownership ...

except I've just now discovered how that fails for me too :(


> >>> should that be a configuration option rather than hard coded?
> >>
> >>I see no reason for having more lax permissions as 640 and stricter
> >>permissions can be modified by umask as said before.
> >
> >Using 0660 might be a reasonable choice for some users in some
> >cases too (such as if you wanted people in the libvirt group to
> >be able to run virt-sparsify on offline images or something like
> >that).  But I'm still building up my own use cases and patterns
> >right now, so I don't have a deep insight into what others might
> >be doing yet ...
> >
> 
> But it's created with the same user virt-manager runs under, so the
> same user will be able to access and modify it.

True, and that would have been great ...  except that's not the user
which qemu runs as, which without dynamic_ownership is a showstopper
for creating new images ...   oops.


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?

  Cheers,
  Ron