Hi Sandro et al, Sandro Knauß: > I now pushed a first version of Akonadi with the new AppArmor profile, but as > you see down here it fails and I'm not sure, what went wrong. What we need to > do to debug this?
[...] >> > I believe the failure may be due to this: >> > >> > Sep 25 09:21:06 merkaba kernel: [ 266.556167][ T37] audit: >> > type=1400 audit(1569396066.434:45): apparmor="DENIED" >> > operation="exec" profile="postgresql_akonadi" name="/bin/dash" >> > pid=3833 comm="pg_ctl" requested_mask="x" denied_mask="x" fsuid=1000 >> > ouid=0 https://salsa.debian.org/qt-kde-team/kde/akonadi/blob/master/debian/apparmor/postgresql_akonadi#L12 reads: /usr/bin/dash mrix, I believe this only does what you mean on a merged-/usr system. I suspect Martin is reporting from a system without merged-/usr. Replacing this line with that one should fix this particular problem: /{usr/,}bin/dash mrix, Hoping it helps :) And regarding the poor UX Martin has experienced when he tried to disable the postgresql_akonadi profile, i.e.: >> apparmor="DENIED" operation="exec" info="profile transition not >> found" error=-13 profile="/usr/bin/akonadiserver" >> name="/usr/lib/postgresql/11/bin/pg_ctl" pid=5261 >> comm="akonadiserver" requested_mask="x" denied_mask="x" fsuid=1000 >> ouid=0 … that's because Px supports no fallback option in case the destination profile of the transition is not enabled. I would suggest using PUx instead of Px in usr.bin.akonadiserver, so that disabling the postgresql_akonadi profile yields behaviour closer to what users would rightfully expect. For details, see the "Access Modes" section in apparmor.d(5). Cheers, -- intrigeri