Hi,
Afaict it’s not possible to suppress apparmor DENIED log messages selectively, is that still correct? This was discussed a few years ago, bringing it up to see if the situation has changed.
Use case: upstream Ceph likes to exercise some syscalls and binaries which we intentionally don’t want to allow in MicroCeph. That works fine, however it tends to spam the logs with DENIED messages, with the associated cost in disk space, operator attention, etc. We could patch upstream Ceph to not attempt to exercise these features, but this would mean carrying a set of fairly invasive patches, resulting in maintenance burden etc.
So from this perspective it would great to be able to tell snappy that we indeed want something denied, are aware of it, and it’s ok not to log these events
It is possible to “deny” without “audit”. And this is done for example for NetworkManager snapd/interfaces/builtin/network_manager.go at b5866dac23c1c7d6e627ff452f5007c169684f6c · canonical/snapd · GitHub
I have tried to run microceph, but I did not see much garbage apart from 1 system call. If you could provide us with what are the known denies that get in the audit, we could just add them in the apparmor profile for microceph-support interface.
I’m getting several of these:
2026-04-17T16:33:26.818829+00:00 vm-quick kernel: audit: type=1400 audit(1776443606.817:190): apparmor=“DENIED” operation=“exec” class=“file” profile=“snap.microceph.osd” name=“/usr/bin/sudo” pid=8524 comm=“admin_socket” requested_mask=“x” denied_mask=“x” fsuid=0 ouid=0
There also was a user reporting cpu.max access being requested repeatedly although I didn’t see this myself
HI @petersabaini,
Did you perhaps manage to test PR16950?
Thanks @valentind and @ernestl , can confirm that the log messages are suppressed
As a PS, I think it might be interesting to give snap developers a way to suppress log messages in a declarative way e.g. inside snapcraft.yaml, as requiring snapd code changes doesn’t scale very well
