[apparmor] Bug#735470: Fwd: Bug#735470: Could be implemented centrally with a dpkg trigger instead of requiring every package shipping an apparmor file to use dh_apparmor

[Seth Arnold]

On Thu, Jan 16, 2014 at 02:57:52PM -0800, John Johansen wrote:
> Is there a way for a trigger to notice which file was updated?
> That way we could use a trigger.
> 
> If not another option that comes to mind is we could add a new flag to the
> parser that would say reload only if the cache is out of date.
> 
> The trigger would have to still do work figuring out which cache files
> are out of date but thats still better than reloading everything to the
> kernel.

One of my work-items for 14.04 LTS is to rework the AppArmor policy
loading.

Currently, the initscript does some work to figure out which profile files
to load, which ones to ignore, and calls the parser individually for each
file. There are (in Ubuntu) profiles in both /etc/apparmor.d/ and in
/var/lib/apparmor/profiles/.

The initscript also attempts to manage the caches; 'service apparmor
restart' or 'service apparmor stop' actually deletes the entire cache
regardless if it makes sense to do so.

I'd like the parser to take on as many of the tasks from the initscripts
as possible. Clearing the cache is a bad idea when stopping or restarting
the AppArmor "service", and in the usual case of "service apparmor start",
I'd like the parser to be in charge of determining which files to load
and if the cached profiles can be read. (This could remove some 30-50
or more fork+exec()s of the parser.)

Perhaps the parser should also be extended to determine if a loaded
profile is older than the cached profile or the plaintext profile; I
believe the parser currently loads the profiles it was asked to load
regardless if the kernel already has the identical profile already loaded.

If dh_apparmor doesn't currently use --write-cache we should make it do
so, to allow the compilation to be saved for later. Same with the click
packaging hooks.

Upstart currently has some AppArmor policy knowledge built-in. We should
also make sure it Does The Right Thing, ideally that'd be mostly up to
the parser to get correct.

I'm sure there's more I've over-looked, I've not looked at this for a
while, so please feel free to speak up if I've overlooked important
considerations.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140116/f692b437/attachment.pgp>