[pkg-apparmor] Bug#796589: Bug#796589: Bug#796589: apparmor: Has init script in runlevel S but no matching service file

Seth Arnold seth.arnold at canonical.com
Wed Aug 26 20:08:03 UTC 2015


On Wed, Aug 26, 2015 at 08:00:16PM +0200, Felix Geyer wrote:
> > [Service]
> > Type=oneshot
> > ExecStart=XXX
> > ExecReload=XXX
> > ExecRestart=XXX
> > ExecStop=XXX
> 
> There is no ExecRestart, systemd translates restart to stop/start.
> That makes it a bit challenging to have a well-defined reload/restart actions.
> 
> Currently we do this in the init script:
> - start: load all profiles
> - stop: clear cache
> - reload/restart: clear cache, load profiles, unload obsolete profiles
> 
> Why does it clear the cache? Is the cache invalidation known to be problematic?

I think "stop clears cache" was a bandaid to fix a cache invalidation
issue. Since it was so painful, it also had bandaids to try to keep stop
from running all that often. Last time I looked into this I was driven
to insanity -- especially since it wasn't clear what was historical
holdover from ancient civilzations and what was actually necessary today.

> Imho ideally we'd do this:
> - start/reload: load all profiles, unload obsolete
> - stop: nop
> 
> Iirc detecting/unloading obsolete profiles is a bit expensive so we might not want to do
> that on boot though.

I don't really like the "unload obsolete" idea much: "the system" policies
are in /etc/apparmor.d/. Ubuntu touch / snappy has entire second set
of policies for "apps" / "snaps" stored in /var/ somewhere. Perhaps
other services exist that generate profiles on the fly or store them
somewhere else and unloading them just because they don't also exist in
/etc/apparmor.d/ feels like a mistake.

Darix mentioned that systemd units can be parameterized; could this
functionality be used to load profiles from multiple directories? Does it
buy us anything?

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-apparmor-team/attachments/20150826/21f55ded/attachment.sig>


More information about the pkg-apparmor-team mailing list