[libvirt] [PATCH] AppArmor: allow virt-aa-helper read access to Nova's qcow backing files.

[Christian Ehrhardt]

On Mon, Jun 11, 2018 at 9:41 AM, Michal Prívozník <mprivozn at redhat.com>
wrote:

> On 06/11/2018 08:43 AM, Christian Ehrhardt wrote:
> > On Mon, Jun 11, 2018 at 8:12 AM, Michal Prívozník <mprivozn at redhat.com>
> > wrote:
> >
> >> On 06/11/2018 07:34 AM, Christian Ehrhardt wrote:
> >>>
> >>> <snip/>
> >> Thank you for your exhaustive explanation. You've convinced me that it's
> >> safe to merge this patch. However, what I still don't quite understand
> >> is: Nova uses that path for ages, doesn't it? How come we've hit the bug
> >> only now?
> >>
> >
> > 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.
> > And all that have done further have done local overrides.
>
> Ah, that explains it.
> >
> >>>
> >>> On Sun, Jun 10, 2018 at 9:08 AM, Michal Prívozník <mprivozn at redhat.com
> >
> >>> wrote:
> >>>
> >>>> On 06/09/2018 09:29 PM, intrigeri+libvirt at boum.org wrote:
> >>>>> From: intrigeri <intrigeri+libvirt at boum.org>
> >>>>>
> >>>>> As reported on https://bugs.debian.org/892431, without this rule,
> when
> >>>> launching
> >>>>> a QEMU KVM instance, an error occurs immediately upon launching the
> >> QEMU
> >>>>> process such as:
> >>>>>
> >>>>>   Could not open backing file: Could not open
> >>>>>   '/var/lib/nova/instances/_base/affe96668a4c64ef380ff1c71b4cae
> >>>> c17039080e':
> >>>>>   Permission denied
> >>>>>
> >>>>> The other instance disk images are already covered by the existing
> >> rule:
> >>>>>
> >>>>>   /**/disk{,.*}
> >>
> >> Oh, I can't merge the patch as-is because it is missing S-O-B line which
> >> is required (https://libvirt.org/hacking.html). Also, it would be nice
> >> if you can use your real name.
> >>
> >
> > We had the real name discussion before, but at least the S-O-B as agreed
> > last time should be added.
>
> To my recollection even the usage of real name is a must (although we
> don't have any means to verify that). Anyway, the point being we don't
> allow any nicknames, TLAs (three letter acronyms), and so on. IANAL, but
> I guess the reason for that is to protect libvirt from any future lawsuits.
>
> >
> > 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.
> > To avoid coming back every few months adding another such line :-)
>
> Well, yes we can add them. However, at that point I guess we might want
> to revisit virt-aa-helper design? I mean, it's nice that we have two
> step permission building, but then we might end up chasing changing
> consumers of libvirt. So I guess if we want to preserve the two step
> process we should encourage libvirt consumers to write their own rules
> and have virt-aa-helper match against that. Of course, libvirt would
> still provide some sensible default so that it works out of box, but in
> this case OpenStack would provide an additional file to enable access to
> /var/lib/nova/... (which is a private path to Nova and could be
> considered internal implementation of Nova and therefore libvirt should
> not care). Also, whenever there's a patch changing the path in Nova code
> base it can be coupled with apparmor profile adjustment.
>
> I'm not sure if there's a way to achieve this.


There are optional incldues coming as a new feature in apparmor.
I have it on my todo list but have to wait a bit until that level of
apparmor is more widely available.
I have thought about that for user driven per guest overrides so far.
Allowing something like a conf.d directory might be possible - need to
evaluate that.

I added (mostly a note to myself) on
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1745114

For now on this patch here we are waiting for the S-O-B resubmit of
intrigeri then you can consider it acked-by by me and push it.

Perhaps we could have a
> separate directory and all other projects would store their profiles
> there and libvirt would just include them all (among with the defaults
> file described above). Then virt-aa-helper would generate its own rules
> in second step.
>
> Michal
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180611/94379910/attachment-0001.htm>