AppArmor denials to cpu.max and sudo

[nobuto-m]

In a Sunbeam deployment, microceph triggers the highest number of AppArmor denials out of many components.

# journalctl -k | grep 'apparmor="DENIED" .*profile="snap.microceph' | awk '{print $12}' | sort | uniq -c
    336 profile="snap.microceph.microceph"
      8 profile="snap.microceph.mon"
      8 profile="snap.microceph.osd"

Each part of the snap tries to access the following path, and it's rejected by AppArmor. Those should be reviewed and allowed if it's expected access or rejected explicitly and suppress the output.

[snap.microceph.microceph]
/var/lib/snapd/hostfs/run/cilium/cgroupv2/system.slice/snap.microceph.microceph-*.scope/cpu.max

[snap.microceph.mon / snap.microceph.osd]
/usr/bin/sudo

From my past experience, some functions in Ceph relies on sudo to invoke an external binary such as smartctl/nvme. e.g. https://bugs.launchpad.net/charm-ceph-osd/+bug/2031637

[sabaini]

Thanks @nobuto-m . Unfort. it seems we can't selectively suppress logging apparmor denials in snappy. We'll need to investigate what we can do to decrease log spam here

[sabaini]

PS: I can indeed see the lots of requests for sudo, however in my test system theres no cpu.max denials. Could you post some of these as a sample and maybe details of the setup for repro?

[nobuto-m]

@sabaini As you see, the path includes cilium so I guess that's one of the triggers including Sunbeam. I will paste sosreport or something when I get there.

[nobuto-m]

kern.log

[nobuto-m]

The full sosreport:
https://bugs.launchpad.net/snap-openstack/+bug/2148796/+attachment/5963133/+files/sosreport-sunbeam-single-node-2026-04-19-qzbsanm.tar.xz

[syncronize-issues-to-jira]

Thank you for reporting your feedback to us!

The internal ticket has been created: https://warthogs.atlassian.net/browse/CEPH-1762.

This message was autogenerated