[apparmor] [PATCH 2/6] libapparmor: Rename aa_policy_cache_create

[Steve Beattie]

On Thu, Mar 26, 2015 at 10:08:26AM -0500, Tyler Hicks wrote:
> On 2015-03-25 23:46:26, Steve Beattie wrote:
> > On Wed, Mar 25, 2015 at 05:37:17PM -0500, Tyler Hicks wrote:
> > > The aa_policy_cache_create() function had a name that didn't quite match
> > > its actions. It doesn't create a new policy cache. It actually requires
> > > an existing policy cache, with some sort of .features file, to already
> > > exist.
> > > 
> > > It unconditionally makes a policy cache "valid" by clearing all of the
> > > files and creating a new .features file from the current running kernel.
> > 
> > Given that, perhaps aa_policy_cache_reset() + a lavender bikeshed? 
> 
> Hmm... I do like reset better for the current implementation but there's
> more to the story with this function.
> 
> We currently have a cache structure like this:
> 
>  /etc/apparmor.d/cache/
>                  ↳ .features
>                  ↳ usr.bin.foo
>                  ↳ usr.bin.bar
> 
> You'd make these calls to check the validity of the cache and reset it if
> the .features file doesn't match the current kernel:
> 
>  aa_policy_cache_new(&policy_cache, NULL, /etc/apparmor.d/cache, false);
>  if (!aa_policy_cache_is_valid(policy_cache))
>      aa_policy_cache_make_valid(policy_cache)
>  
> However, we'll soon have multiple policy cache directories for various kernels.
> The layout will look something like this (this is not set in stone yet):
> 
>  /etc/apparmor.d/cache.d/
>                  ↳ 60b725f10c9c/
>                    ↳ .features
>                    ↳ usr.bin.foo
>                    ↳ usr.bin.bar
>                  ↳ 3b5d5c371295/
>                    ↳ .features
>                    ↳ usr.bin.foo
>                    ↳ usr.bin.bar
>                  ↳ 2cd6ee2c70b0/
>                    ↳ .features
>                    ↳ usr.bin.foo
>                    ↳ usr.bin.bar
> 
> The directory names underneath the cache.d directory are some sort of hash. The
> implementation is private to libapparmor but the inputs may be the text
> representation of a kernel's AA features.
> 
> Lets say that the current kernel's AA features hash to "e29311f6f1bf",
> which doesn't yet have a valid cache directory. The
> aa_policy_cache_make_valid() function will be what creates the new cache
> subdirectory and the corresponding .features file.

I'm a little confused, the reason "create" didn't make sense was because
it didn't ever create the directory. But in the future, we expect the
function to go ahead and create the new cache subdirectory. So it seems
like "create" or "init" would work for the function name, perhaps the
latter since it also makes it valid by creating the .features file,
which would still cover the existing situation.

(Or possibly have two functions a _reset and an _init, where the
latter creates the directory and calls the former. But I'm not
convinced that's necessary.)

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20150326/4aec7312/attachment.pgp>