AppArmor denies access to /sys/block/*/queue/max_segments
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
Since Cockpit's "ubuntu stable" VM image got updated from Ubuntu 17.04 to 17.10, the libvirt tests now cause several instances of this AppArmor denial:
Nov 02 10:19:28 unassigned-hostname audit[1347]: AVC apparmor="DENIED" operation="open" profile=
It does not actually break anything, but QEMU might use this for some optimizations? Reading this kind of hardware information from /sys seems harmless and useful enough to allow it in the profile.
Note: This seems to be a race condition, I cannot trivially reproduce it locally. Thus the extra Apport information here does not contain the violation. But I attach the journal from an instance that does.
ProblemType: Bug
DistroRelease: Ubuntu 17.10
Package: libvirt-daemon 3.6.0-1ubuntu5
ProcVersionSign
Uname: Linux 4.13.0-16-generic x86_64
ApportVersion: 2.20.7-0ubuntu3
Architecture: amd64
Date: Thu Nov 2 11:11:02 2017
SourcePackage: libvirt
UpgradeStatus: No upgrade log present (probably fresh install)
Qemu function hdev_get_ max_segments reads this. block/% u:%u/queue/ max_segments with O_RDONLY block/* /queue/ max_segments r," should be good.
Access is to: /sys/dev/
So yeah, the rule "/sys/dev/
This is since qemu 2.9: 150bcbc3c9a4fbc 72b47fedcc
commit 9103f1ceb46614b
Author: Fam Zheng <email address hidden>
Date: Wed Mar 8 20:08:14 2017 +0800
file-posix: Consider max_segments for BlockLimits. max_transfer
This is a fix for a rare bug, that due to the rule does not yet "fix" it.
Prio is low enough to not need any SRU, but it shall be fixed.
I'll create a fix to the upstream apparmor profiles and get them back on next merge.