Questions regarding partial policy load, and the future

[Jamie Strandboge]

On Fri, 2010-06-18 at 16:26 -0700, John Johansen wrote:
> On 06/18/2010 01:00 PM, Kees Cook wrote:
> > Hi John,
> > 
> > On Fri, Jun 18, 2010 at 12:19:27PM -0700, John Johansen wrote:
> >> However there are several reasons to change this and have policy, or
> >> parts of policy, sharing information and loaded together.  The caveat
> >> is that with sharing the ability to load profiles separately is lost.
> >> So the question becomes how important is being able to load profiles
> >> individually?  How often are individual profile reloads used instead of
> >> just reloading all of policy through the init scripts?
> > 
> > Right now, all the time.  The idea of on-demand loading for only things
> > that are about to start up is how it's split up now to spread out the
> > potential load times.
> > 
> Right, at the moment we have split load, where we load the early set
> and then, reload the whole set later.

There is that, but in Ubuntu when installing/updating a package with a
profile we have shifted away from reloading all policy
(eg /etc/init.d/apparmor reload) to reloading individual profiles (eg
apparmor_parser -r <profile>). This was done primarily for speed
improvements during package install/upgrades. Of course, when Ubuntu
transitioned to doing this it was before we used cached profiles, so I
imagine the benefits of doing so now are not that great (ie, we install
a new cups profile, and then do a '/etc/init.d/apparmor reload' -- with
caching, the load of the cached profiles is nearly instantaneous so the
user only really feels the compilation of the new policy, as opposed to
before, when all the profiles were recompiled). 

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/apparmor/attachments/20100619/9da38511/attachment.pgp