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

[Martin Kletzander]

On Thu, Jul 03, 2014 at 12:41:57AM +0930, Ron wrote:
>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?
>

Multiple domains with different definitions for example.

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

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 or as a dac seclabel in
the XML definition.

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

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20140703/df0d22d7/attachment.sig>