Bug#941118: akonadi-server: fails to start after upgrade to 4:18.08.3-8: apparmor denied access to pg_ctl

[intrigeri <intrigeri@debian.org>]

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