Hi,
if a package drops a file into /etc/apparmor.d/apache we should do a

      apparmor_parser -r /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2

if apparmor is enabled. Since dh-apparmor has all the logic to detect
that aa is in use it would be great if it would handle this case as
well. This would make sure we handle things like #872266 too once fixed.
Cheers,
 -- Guido

Hi,

Guido Günther:

I can't find any such profile in current sid. Apparently since a few
years it's rather something like "if a package drops a file in
/etc/apparmor.d/apache2.d then we should reload the usr.sbin.apache2
profile". Right?

Agreed, this would be a nice addition! :)

FTR I don't use AppArmor for Apache personally so there's very little
chance I work on this any time soon. Patches are welcome.

Now you make me curious: I don't understand how this is related.

Cheers,

Hi,

Since it's still sitting in new ;)

https://anonscm.debian.org/cgit/pkg-giraffe/kopano-webapp.git/commit/?id=7310d19e1de2bb028f81a5971de724e7af62d5a5

Exactly!

I just meant to say that once dh-apparmor unloads profiles this would
then automatically work for the above case as well once added to
dh-apparmor. So we get consistency within Debian (rather than having
some applications unload the profile on removal while others don't).
Cheers,
 -- Guido

Hi,

FTR, there's no real-world example in testing anymore of the exact use
case why this was requested initially:

 - kopano-webapp was orphaned, removed from testing, and it's unlikely
   to come back any time soon.
 - We don't ship usr.lib.apache2.mpm-prefork.apache2 anymore.

But:

 - We still ship usr.sbin.apache2 with "#include <apache2.d>".
 - It's no surprise that other packages don't do this sort of things,
   given it's not well supported by our packaging machinery.

So I'm generalizing this bug report.

Notes to whoever will work on this:

 - To me it screams "dpkg triggers", since they provide the kind of
   facility we need here, i.e. ensure package X is informed it shall
   do something whenever package Y is installed/updated/removed.
   In the example at hand, libapache2-mod-apparmor would be triggered
   and would reload the usr.sbin.apache2 profile, whenever a package
   adds/updates/removes bits in /etc/apparmor.d/apache2.d/.

 - I think the right thing to do depends on how the plugin integration
   is done wrt. non-AppArmor aspects. For example, if
   adding/updating/removing a plugin package does *not* restart the
   affected program, then I think we should not reload the AppArmor
   policy either: otherwise, we would confine an older, already
   running, version of the code, with a new version of the AppArmor
   policy, and they may very well be incompatible.

Cheers!

See also https://bugs.debian.org/872266, which is also about policy
that confine programs shipped in other packages.