All default AppArmor profiles are currently provided as part of package
'apparmor-profiles'.

That's all well and good as long as only official SUSE-provided packages are
installed for the applications protected by AppArmor. When you start installing
3rd-party packages for the same application, that system breaks down, because
the 3rd-party build of the application may not have the exact same
requirements, meaning its startup may get blocked by AppArmor.

The workaround we put in place was to use the mechanism of include files (in
'/etc/apparmor.d/local/') to cover the extra access rights needed. But it would
be much cleaner if the 3rd-party vendor could provide their own AppArmor
profiles as a sub-package of their application.

In the current situation, that's not possible, as they would need to overwrite
a (set of) file(s) provided by another package.

Case in point: the Samba 4 packages built by SerNet GmbH. Their daemons are
prevented from starting by the following (default OpenSUSE) profiles:

- /etc/apparmor.d/usr.sbin.nmbd
- /etc/apparmor.d/usr.sbin.smbd
- /etc/apparmor.d/usr.sbin.smbldap-useradd
- /etc/apparmor.d/usr.sbin.winbindd

I guess a possible alternative solution (through perhaps less flexible) would
be to remove local include files "placeholders" from '/etc/apparmor.d/local/'
(while keeping the '#include' directive in the master file).

This way, 3rd-party vendors could safely package files destined to land below
'local/' (but the drawback, if I understand correctly, is that permissions
granted in the master file could not easily be revoked by the included file if
needed).