Comment 3 for bug 1641618
Revision history for this message
| Simon Déziel (sdeziel) wrote Re: [Bug 1641618] Re: Apparmor denials caused by virt-aa-helper trying to read zvol devices (/dev/zdX) should be silenced | #3 |
Hello Christian,
On 2016-11-22 05:06 AM, ChristianEhrhardt wrote:
> those changes (the whole part after "/sys/devices/** r,") never made it upstream and was actually dropped in the merge of libvirt 2.x for Yakkety.
> Maybe that also moved and this is "only" needed in Xenial and actually fixed in >=Yakkety already?
Good point. I only use LTS releases so I don't know the answer to that.
> And looking back - nobody complained on the yakkety merge that smb did - hrm ..?
> Eventually (like some day) we want to get rid of apparmor delta and that was one step.
Yes and that's something I'd like to work on when time will permit.
> Simon:
> - Can you describe the "noise" it makes to you?
[Tue Oct 18 12:25:29 2016] audit: type=1400 audit(147680792
apparmor="DENIED" operation="open"
profile=
comm="virt-
> - Having the old rules you were on Xenial right?
Yes, Xenial here.
> - Does it match what I found?
Yes
> - The old bug only has "Per discussion on irc, I'll add a deny rule to usr.lib.
I don't remember that IRC discussion and have no log of it either, sorry.
virt-aa-helper is already denied from accessing those backing files
Preventing virt-aa-helper from accessing the backing file doesn't cause
any problem as far as I could see. The guest's profile still get the
right "/dev/zdXX rw," line added to it's libvirt-UUID.files file. Same
goes for LVs where a "/dev/dm-X rw," is added.
I don't know why virt-aa-helper tries to read those backing files.
Logically, I would expect such read access for backing files that are
stack-able like QCOW2. Reading the file referenced in the .xml would let
virt-aa-helper learn about any other backing file that needs to be
exposed to the VM. Maybe that is why read access to all .qcow2 is
granted? That's just a wild guess though.