Hello, a short discussion with Marcus at the conference brought up an issue with packaging AppArmor profiles: When a package containing an AppArmor profile is installed or updated, the profile is not (re)loaded. This means it will only become active when the admin actively reloads the profiles or when the machine is rebooted. Until then, either the previous profile is used (update case) or the application will run unprotected (if a new profile was installed). This mail is a first draft on how to handle this. Instead of re-inventing the wheel ;-) I asked upstream (which is basically Ubuntu) and got the information that they use this debhelper: http://bazaar.launchpad.net/~ubuntu-core- dev/apparmor/master/files/head:/debian/debhelper/ The most interesting part is probably postinst-apparmor, which can be the base for a %post macro. (IMHO creating the local/ sniplet shouldn't be part of that macro. Maybe we should create a separate macro for it, but that's a minor issue.) I propose the following macro to be used in %post: (untested ;-) %apparmor_profile_post() \ # Reload the profile, including any abstraction updates \ if aa-status --enabled 2>/dev/null; then \ apparmor_parser -r -T -W "/etc/apparmor.d/%1" || true \ fi This will (re)load the profile if both apparmor-utils (aa-status) and apparmor-parser are installed and apparmor is enabled. Otherwise it will just fail silently. Usage in %post: %apparmor_profile_post usr.sbin.foo (where "usr.sbin.foo" is the filename of the profile in /etc/apparmor.d) Another question is directory ownership of /etc/apparmor.d/ and the availability of the abstractions and tunables (which are used by nearly every apparmor profile). The easiest way would be to add Requires: apparmor-profiles to every package shipping an apparmor profile. Note that apparmor-profiles contains some profiles itsself, which would then also become active (unless someone disables them manually). Do you think this is a problem? (If yes, I can split the abstractions and tunables into a separate package.) And a final question: Into which package should I put the rpm macro? (This package will then also be needed in BuildRequires:) libapparmor-devel doesn't sound right because most packages don't need libapparmor, and I also don't like the idea of creating an apparmor- devel just for this file. Remaining candidates are apparmor-profiles[1] and apparmor-parser. apparmor-profiles[1] would have the advantage to also solve the "unpackaged directory" warnings for /etc/apparmor.d/ (Unless someone doesn't like to have the rpm macro in the apparmor- profiles[1] package, it's my favorite for now ;-) Maybe I'll also create another macro %apparmor_requires containing the Requires: and BuildRequires:, but that's a technical detail ;-) (In this case, the more interesting question is where the %apparmor_requires macro should be packaged - storing it in an apparmor package would cause a chicken-egg problem ;-) As usual: feedback welcome ;-) Regards, Christian Boltz [1] or apparmor-abstractions if we decide to split the abstractions into a separate package -- F: Word? Was ist das? A: Das ist wohl das Programm, das ursrpünglich einmal Text heißen sollte. Da es aber für längere Dokumente ungeeignet ist, wurde es umbenannt. Inzwischen kann es aber bereits 97 Wörter verwalten. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org