[apparmor] apparmor cache dir error messages

[John Johansen]

On 5/19/21 2:31 PM, Christian Boltz wrote:
> Hello,
> 
> Am Dienstag, 18. Mai 2021, 19:54:55 schrieb mailinglisten at posteo.de:
>> Am 17.05.21 um 23:50 schrieb Christian Boltz:
>>>> (...)
>>>>
>>> In theory the packaged pre-compiled cache should match the kernel so
>>> that the directory actually gets used. Your error message indicates
>>> that there is a mismatch - did you install a non-default kernel?
>>> (And BTW, which distribution do you use?)
>>
>> opensuse leap 15.2 and actually I do use a non default kernel
> 
> OK, that non-default kernel explains why the packaged cache doesn't get 
> used.
> 
>>> The directory is probably part of a package you've installed [1],
>>> therefore I'd recommend to keep it. (Deleting it won't break
>>> AppArmor, but your package manager might start to complain about
>>> the missing files.)
>>
>> I would expect a cache directory below /var and actually there is also
>> a cache dir, /var/lib/apparmor/cache/ that contains just a hidden
>> filed named .features.
> 
> That's an old cache location (up to AppArmor 2.12). IIRC we had to use 
> it because of the quite complex btrfs layout older openSUSE releases 
> used (with several /var/$whatever subvolumes) + the condition that the 
> cache should be available as early as possible on boot.
> 
> Newer openSUSE releases have the btrfs subvolumes simplified a lot, 
> which also allowed to move the cache to /var/cache/apparmor/ starting 
> with AppArmor 2.13. This directory should contain at least one 
> subdirectory with cache files that match your running kernel.
> 
>> What is the benefit of a pre-compiled cache in contrast to the
>> profiles in /etc/apparmor.d/?
> 
> The profiles get loaded faster, which is especially noticable on boot.
> 
> The exact numbers depend on the profiles you have. For example, on my 
> laptop (with several additional non-default profiles, it's 7 seconds 
> without cache vs. 0.2s when using the cache.
> 
Beyond loading faster there are a few of other benefits, though not all
will apply to desktop systems
- if the cache is in the right place, it allows for early (very early)
  profile loads. Which is required if you want to do things like confine
  init.
- it allows shipping prebuilt policy as part of an RO system image.
  This is very useful for low mem/low power embedded devices. Part of
  this is faster boots but also that compiles can require too many
  resources for some of these device.
- it allows for systems without the apparmor_parser or tools