Bug#828795: ioquake3: postinst call non-existing aa-enabled

[Simon McVittie]

Control: reassign 828795 dh-apparmor 2.10.95-2
Control: severity 828795 minor

On Mon, 27 Jun 2016 at 23:21:05 +0200, Alexandre Detiste wrote:
> postinst script call non-installed "aa-enabled" and generate errors.
...
> Paramétrage de ioquake3-server (1.36+u20160616+dfsg1-1) ...
> /var/lib/dpkg/info/ioquake3-server.postinst: 22:
> /var/lib/dpkg/info/ioquake3-server.postinst: aa-enabled: not found
> Paramétrage de ioquake3 (1.36+u20160616+dfsg1-1) ...
> Installation de la nouvelle version du fichier de configuration
> /etc/apparmor.d/usr.lib.ioquake3.ioquake3 ...
> /var/lib/dpkg/info/ioquake3.postinst: 22: /var/lib/dpkg/info/ioquake3.postinst:
> aa-enabled: not found

I believe this is caused by recent changes to the dh_apparmor autoscript:

--- debian/debhelper/postinst-apparmor	2016-04-24 14:14:30 +0000
+++ debian/debhelper/postinst-apparmor	2016-06-24 13:13:39 +0000
@@ -16,9 +16,7 @@
         }
 
         # Reload the profile, including any abstraction updates
-        rc=0
-        aa-status --enabled 2>/dev/null || rc=$?
-        if [ "$rc" = 0 ] || [ "$rc" = 2 ]; then
+        if aa-enabled --quiet; then
             apparmor_parser -r -T -W "$APP_PROFILE" || true
         fi
     fi

The primary change here was to move from the Python aa-status --enabled
to the C aa-enabled, but a side-effect was to lose the "2>/dev/null".

The postinst ignores an AppArmor-detection command that does not exist,
treating it as equivalent to the unsuccessful exit status that would
indicate that the apparmor user-space tools are installed but the actual
LSM was not enabled in the kernel during boot. I think that's correct
here: if we don't have the apparmor user-space tools, we should just
not load the profile and carry on, the same as we would do if we had
the tools but the LSM wasn't enabled.

However, dropping the 2>/dev/null means that the postinst emits a message
that misleads users into thinking the package is missing a dependency on
apparmor or something.

As far as I understand the AppArmor maintainers' policy on how AppArmor
fits into Debian, we specifically do not want random packages that
happen to support AppArmor as an extra layer of hardening, like ioquake3,
to depend on apparmor. I could add a Suggests if people want that, but it
shouldn't be any stronger: it's entirely normal to use ioquake3 without
AppArmor.

    S