parser.conf does not support config extension via snippets

[Fabian Grünbichler]

parser.conf is currently not extensible via a snippet or include mechanism (there is an "Include" config directive, but it just sets the search path(s) for include statements in profiles).

I'd like to introduce such a mechanism (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883682 for concrete use case, but I think it is a good idea in general).

taking a quick look at the existing parser code makes it seem like it should not be too hard by reusing process_config_file..

there are two possible semantics:
- parse snippet/extension config files after main parser.conf is completely parsed
- parse snippet/extension config files recursively while parsing parser.conf

I'd prefer the former, in any case it should be clearly documented.

if this is something you'd be interested in I'd just spin up an initial draft patch, and we could continue from there..

[John Johansen (jjohansen)]

On 12/07/2017 12:43 AM, Fabian Grünbichler wrote:
> Public bug reported:
>
> parser.conf is currently not extensible via a snippet or include
> mechanism (there is an "Include" config directive, but it just sets the
> search path(s) for include statements in profiles).
>
> I'd like to introduce such a mechanism (see https://bugs.debian.org/cgi-
> bin/bugreport.cgi?bug=883682 for concrete use case, but I think it is a
> good idea in general).
>
> taking a quick look at the existing parser code makes it seem like it
> should not be too hard by reusing process_config_file..
>
> there are two possible semantics:
> - parse snippet/extension config files after main parser.conf is completely parsed
> - parse snippet/extension config files recursively while parsing parser.conf
>
> I'd prefer the former, in any case it should be clearly documented.
>
> if this is something you'd be interested in I'd just spin up an initial
> draft patch, and we could continue from there..
>

Lets hold off on this, an alternative proposal that should fix the majority
of the problems you are seeing is coming. Once the proposal (not the patches)
lands, we can discuss and see if you believe this should still be done

the proposal has multiple parts but it basically comes down to

1. There will be multiple cache files so we won't have the same problem
   switching kernels. This work is largely already done

   https://gitlab.com/apparmor/apparmor/merge_requests/4

2. Policy is going to be version directly, pinning will become a fallback
   for unversioned policy.