<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 11, 2018 at 8:12 AM, Michal Prívozník <span dir="ltr"><<a href="mailto:mprivozn@redhat.com" target="_blank">mprivozn@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 06/11/2018 07:34 AM, Christian Ehrhardt wrote:<br>
> Hi Intrigeri and Michal,<br>
> IMHO this is the right path as it is stage one of the two stage process to<br>
> allow images for guests with apparmor.<br>
> <br>
> Stage 1:<br>
> Virt-aa-helper has to be allowed to access the paths to evaluate images for<br>
> some attributes and e.g. backing chains.<br>
> Due to that virt-aa-helper needs access to the paths we expect the images<br>
> in.<br>
> Further more uncommon paths shall be handled by a local include #include<br>
> <local/usr.lib.libvirt.virt-<wbr>aa-helper> where a user can add his special<br>
> cases.<br>
> <br>
> Stage 2:<br>
> virt-aa-helper generated the guest apparmor profile, and in there will be<br>
> entries for all the used image files of a backing chain.<br>
> The guest can work due to the file allowing this.<br>
> <br>
> With virt-aa-helper not able to read those paths in stage1 some entries<br>
> might be missing for stage2.<br>
> IMHO here the suggestion is just to open up stage1 a bit to get it working.<br>
> <br>
> But if that is right and we are considering the change, the we should go<br>
> further and add more.<br>
> As a background, I had the proposed rule in Ubuntu for quite a while,<br>
> together with a bunch of other common (for us) paths.<br>
> I always considered them a downstream decision as nova could have been<br>
> somewhere else for other downstreams.<br>
> The same applies to paths for other tools.<br>
> <br>
> In fact you'll see in the rules that there is some history to this with not<br>
> only nova, but also eucalyptus, then the ubuntu specific uvtool as well as<br>
> two snap specific paths which actually would be useful everywhere.<br>
> <br>
> +  # nova base images (LP: #907269)<br>
> +  /var/lib/nova/images/** r,<br>
> +  /var/lib/nova/instances/_base/<wbr>** r,<br>
> +  # nova snapshots (LP: #1244694)<br>
> +  /var/lib/nova/instances/<wbr>snapshots/** r,<br>
> +  # nova base/snapshot files in snapped nova (LP: #1644507)<br>
> +  /var/snap/nova-hypervisor/<wbr>common/instances/_base/** r,<br>
> +  /var/snap/nova-hypervisor/<wbr>common/instances/snapshots/** r,<br>
> +  # eucalyptus (LP: #564914)<br>
> +  /var/lib/eucalyptus/instances/<wbr>**/disk* r,<br>
> +  # eucalyptus loader (LP: #637544)<br>
> +  /var/lib/eucalyptus/instances/<wbr>**/loader* r,<br>
> +  # for uvtool<br>
> +  /var/lib/uvtool/libvirt/<wbr>images/** r,<br>
> +  # for multipass<br>
> +  /var/snap/multipass/common/<wbr>data/multipassd/vault/<wbr>instances/** r<br>
> <br>
> Since this is only opening up the paths for virt-aa-helper and not the<br>
> guest it is rather safe.<br>
> And I always likes it more to explicitly list the paths we want instead of<br>
> the almost too global /**/disk{,.*} rule.<br>
> <br>
> So I'm +0.75, lacking the final 0.25 only for the reason of considering it<br>
> a downstream thing so far.<br>
> OTOH if we can agree on the paths I'd totally love to see these paths<br>
> upstream, but then I'd prefer to add like all the paths I referred and not<br>
> only "the one just found".<br>
<br>
</div></div>Thank you for your exhaustive explanation. You've convinced me that it's<br>
safe to merge this patch. However, what I still don't quite understand<br>
is: Nova uses that path for ages, doesn't it? How come we've hit the bug<br>
only now?<span class=""><br></span></blockquote><div><br></div><div>We didn't Ubuntu had this as downstream Delta as long as I can remember - I guess only now someone drives Nova in Debian to that point.</div><div>And all that have done further have done local overrides.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> <br>
> On Sun, Jun 10, 2018 at 9:08 AM, Michal Prívozník <<a href="mailto:mprivozn@redhat.com">mprivozn@redhat.com</a>><br>
> wrote:<br>
> <br>
>> On 06/09/2018 09:29 PM, <a href="mailto:intrigeri%2Blibvirt@boum.org">intrigeri+libvirt@boum.org</a> wrote:<br>
>>> From: intrigeri <<a href="mailto:intrigeri%2Blibvirt@boum.org">intrigeri+libvirt@boum.org</a>><br>
>>><br>
>>> As reported on <a href="https://bugs.debian.org/892431" rel="noreferrer" target="_blank">https://bugs.debian.org/892431</a><wbr>, without this rule, when<br>
>> launching<br>
>>> a QEMU KVM instance, an error occurs immediately upon launching the QEMU<br>
>>> process such as:<br>
>>><br>
>>>   Could not open backing file: Could not open<br>
>>>   '/var/lib/nova/instances/_<wbr>base/<wbr>affe96668a4c64ef380ff1c71b4cae<br>
>> c17039080e':<br>
>>>   Permission denied<br>
>>><br>
>>> The other instance disk images are already covered by the existing rule:<br>
>>><br>
>>>   /**/disk{,.*} <br>
<br>
</span>Oh, I can't merge the patch as-is because it is missing S-O-B line which<br>
is required (<a href="https://libvirt.org/hacking.html" rel="noreferrer" target="_blank">https://libvirt.org/hacking.<wbr>html</a>). Also, it would be nice<br>
if you can use your real name.<span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>We had the real name discussion before, but at least the S-O-B as agreed last time should be added.</div><div><br></div><div>And I'd ask for an opinion on the "other" paths I listed - I can only recommend adding as much as we can commonly agree to be useful.</div><div>To avoid coming back every few months adding another such line :-)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
Michal<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><span style="color:rgb(136,136,136);font-size:12.8px">Christian Ehrhardt</span><div style="color:rgb(136,136,136);font-size:12.8px">Software Engineer, Ubuntu Server</div><div style="color:rgb(136,136,136);font-size:12.8px">Canonical Ltd</div></div></div></div></div>
</div></div>