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

Martin Kletzander mkletzan at redhat.com
Wed Jul 2 11:50:27 UTC 2014


On Wed, Jul 02, 2014 at 07:36:00PM +0930, Ron wrote:
>On Wed, Jul 02, 2014 at 09:02:26AM +0200, Martin Kletzander wrote:
>>On Tue, Jul 01, 2014 at 11:57:11PM +0930, Ron wrote:
[...]
>But yes, let's take this discussion to libvir-list@ once the 1.2.6
>deadline goes whoosh :)
>

Done, the release already happened.

[...]
>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).

[...]
>>>- 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.

Martin

[1] https://www.redhat.com/archives/libvir-list/2014-March/msg00826.html
-------------- 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/20140702/c3a6e771/attachment.sig>


More information about the virt-tools-list mailing list