Hi intrigeri,
On Sat, Jun 04, 2016 at 02:56:39PM +0200, intrigeri wrote:
[..snip..]
> >> To confirm this, we need:
> >>
> >> * the kernel / auditd logs from AppArmor, when the profile is in
> >> complain or enforce mode
>
> [... snipping logs about the parser load/etc. operations ...]
>
> Let me be more specific: I would like to see the log about what
> AppArmor blocks (the corresponding log entries should contain the
> "DENIED" string).
Well, there are no DENIED messages - that's the puzzling part and the
reason for this bug. The should be a all also contain "audit" and end up
in dmesg so my grep expression should have caught them (and I .
> >> * the generated profile (/etc/apparmor.d/libvirt/libvirt-${uuid}*)
>
> > As far as can tell there are no new files generaed with the uuid of the
> > sqs domain.
>
> Hmmm, OK. Here I have to admit that I have no clue how libvirt handles
> AppArmor with qemu:///session; I've never tried it myself, and I don't
> even know if it's supposed to be supported. Can you reproduce this
> problem with qemu:///system?
No, session works as expected. The start of this journay basically was
to find out what aa does to qemu:///ession (at the very best it
should totally ignore it).
> I guess that at some point I should simply try and run your
> autopkgtest myself to investigate, but first if you don't mind I'd
> like a little bit more input from you, until we can be certain whether
> it's a bug in AppArmor or in libvirt's AppArmor integration.
> Fair enough?
Sure. I'm happy to provide more input.
Cheers,
-- Guido
