[apparmor] Policy cache

John Johansen john.johansen at canonical.com
Thu Nov 10 02:50:10 UTC 2011


On 11/09/2011 04:54 PM, Kees Cook wrote:
> On Wed, Nov 09, 2011 at 04:43:44PM -0800, Seth Arnold wrote:
>> On Wed, Nov 9, 2011 at 3:52 PM, Kees Cook <kees at ubuntu.com> wrote:
>>> On Wed, Nov 09, 2011 at 03:38:36PM -0800, John Johansen wrote:
>>>> With that said we should add an option to the apparmor_parser to allow
>>>> setting the cache location.  If an alternate cache location is desired
>>>> a new default could be set in the /etc/apparmor.d/parser.conf file
>>>
>>> I would recommend /lib/apparmor/cache as the new upstream default location.
>>> It should be an option, though, yes.
>>
>> I know /lib is usually available early, but I don't care for the idea
>> of considering it a "writable location". That's what /var is there for
>> -- per-service dynamic storage. If someone wanted a read-only root
>> (where /lib lives on most installations) then we'd be an real
>> annoyance.
> 
> Hrm. So /var by default? And people with /var not in / can relocated it as
> needed? I'd almost rather keep it in /etc. More people more /var than /lib.
> For example, udev uses /etc for cached rules.
> 
This is exactly how the discussion have gone, /etc isn't right, should be
/var, but it might not be available, how about /lib, no /lib shouldn't
be writable that is what /var is for, and around and around ...

And we keep coming back to /etc/ is the best generic default because no
where matches, but /etc/ works and its what we are using already

I am not opposed to moving but we can't seem to agree where, hence lets
just make it configurable and be done with it.

>> The hash need not be this complicated: it could just be:
>>
>> /lib/apparmor/cache/3.2.0-5-generic/f3.1-c2.0-n1.0-ch1.5-cp1.1-ns1.1-r1.1/
>> reduced to:
>> /lib/apparmor/cache/3.2.0-5-generic/31201015111111
> 
> But that means we can't ever go from .9 to .10. I think a hash would be
> fine -- we're just looking for whatever matches.
> 
yes I think the hash will be adequate, especially if we continue with the
practice of putting .features file in the directory, so that if there
ever is a hash collision we can catch it.




More information about the AppArmor mailing list