Description of problem: Yesterdays's selinux-policy update [1] caused a new regression with mdadm:
audit: type=1400 audit(1623380809.049:365): avc: denied { getattr } for pid=1758 comm="mdadm" path="/dev/dma_heap" dev="devtmpfs" ino=127 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:dma_device_dir_t:s0 tclass=dir permissive=0
This was spotted by our regular CI runs on updates-testing [2], but the update was pushed through -testing so fast (< 24 h) that there is no chance in the world to catch and report it.
That update fixed bug 1968654 , which sounds very related -- it fixed the "associate" action on the very same object.
Version-Release number of selected component (if applicable):
How reproducible: Always
Additional info:
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-d8e34dbd6e
[2] https://github.com/cockpit-project/bots/pull/2106
Description of problem: Yesterdays's selinux-policy update [1] caused a new regression with mdadm: audit: type=1400 audit(1623380809.049:365): avc: denied { getattr } for pid=1758 comm="mdadm" path="/dev/dma_heap" dev="devtmpfs" ino=127 scontext=system_u:system_r:mdadm_t:s0 tcontext=system_u:object_r:dma_device_dir_t:s0 tclass=dir permissive=0 This was spotted by our regular CI runs on updates-testing [2], but the update was pushed through -testing so fast (< 24 h) that there is no chance in the world to catch and report it. That update fixed bug 1968654 , which sounds very related -- it fixed the "associate" action on the very same object. Version-Release number of selected component (if applicable): How reproducible: Always Additional info: [1] https://bodhi.fedoraproject.org/updates/FEDORA-2021-d8e34dbd6e [2] https://github.com/cockpit-project/bots/pull/2106