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?
> - 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.libvirt.virt-aa-helper", but I don't really get why it is a deny and not an allow - could you elaborate on that?
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.
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 9.293:265) : "/usr/lib/ libvirt/ virt-aa- helper" name="/dev/zd128" pid=5432 aa-helper" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
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. libvirt. virt-aa- helper" , but I don't really get why it is a deny and not an allow - could you elaborate on that?
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.