<div dir="ltr"><div>Hi,</div><div><br></div><div></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 May 2021 at 13:34, Michal Prívozník <<a href="mailto:mprivozn@redhat.com">mprivozn@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Disks can contain various secrets (passwords, certificates, private<br>
keys, etc.). Historically, libvirt set seclabel on anything that QEMU<br>
needed access to and then returned it to root:root when QEMU no longer<br>
needed it, exactly because we could not tell if some sensitive info was<br>
stored in a file or not.<br>
<br>
With recent enough libvirt (5.6.0 or newer) libvirt remember the<br>
original seclabel (owner + SELinux label) and restores them afterwards.<br>
The mode is untouched though.<br></blockquote><div><br></div><div>Does the typical SELinux label prevent other users on the system from reading the VM image file even if it has o+r set on it? I'm hazy enough on SELinux that I don't want to make any invalid assumptions.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I'd say that if somebody wants a disk to be "shared", e.g. readable by<br>
other users on the system, they can put <shareable/> stanza into disk<br>
XML. But then again - libvirt doesn't change the mode. So I think it's<br>
up to vagrant to decide.<br>
<br>
Michal<br>
</blockquote><div><br></div><div>I think requiring an explicit decision to share is probably the best approach and better to keep that as part of the requirements before enabling o+r on the mode. Thanks, that's a very useful suggestion.<br></div><div><br></div><div>--<br></div><div>Darragh Bailey<br>"Nothing is foolproof to a sufficiently talented fool" <br></div></div></div></div>