Comment 2 for bug 1503762

A real systemd unit file would be best. The trouble with the simple ones is that I don't think they'd be suitable for Ubuntu's uses, since we store AppArmor policy in multiple places depending upon if it is shipped with the core distribution or packages (/etc/apparmor.d) or via snaps or clicks in /var/ somewhere.

The AUR files can be found at:
https://aur.archlinux.org/cgit/aur.git/tree/?h=apparmor

and are quite simple:
[Unit]
Description=AppArmor profiles
DefaultDependencies=no
After=local-fs.target
Before=sysinit.target

[Service]
Type=oneshot
ExecStart=/usr/bin/apparmor_load.sh
ExecStop=/usr/bin/apparmor_unload.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

#!/bin/sh

aa_profiles='/etc/apparmor.d/'
aa_log='/var/log/apparmor.init.log'
/usr/bin/apparmor_parser -r $(find "$aa_profiles" -maxdepth 1 -type f) 2>> "$aa_log"

#!/bin/sh

aa_profiles='/etc/apparmor.d/'
aa_log='/var/log/apparmor.init.log'
PROFILES=`find "$aa_profiles" -maxdepth 1 -type f`
for profile in $PROFILES; do
    apparmor_parser -R "$profile" 2>> "$aa_log"
done

I think what we want instead is a templated systemd file that can work for /etc/apparmor.d/ and /var/whatever/click and /var/whatever/snap/ profiles as well as user-specific profiles in ~/.apparmor/ that can be run with user sessions, whenever we finally get there.

That'd also help remove the complicated calls to find and so forth, since apparmor_parser should be able to handle being called on the directories directly, e.g. apparmor_parser -r /etc/apparmor.d/

I also think 'stop' should be a no-op, since systemd implements 'restart' via separate 'stop' and 'start'; if we actually unload profiles, 'restart' cannot re-confine programs that are running. I'd rather provide a separate aa-unload tool if unloading all profiles is necessary.

I think http://0pointer.de/blog/projects/instances.html is the description for the feature I'm thinking of.

Thanks