[apparmor] RFC: using variables to make profiles more flexible

[John Johansen]

On 12/03/2017 04:05 AM, intrigeri wrote:
> Hi,
> 
> Vincas Dargis:
>> What about actual implementation, should we "push":
> 
>> * `tunables/usr.bin.thunderbird` empty file (same as with local/usr.bin.thunderbird), or
>> * `tunables/usr.bin.thunderbird.d` directory for more flexibility, but without a file (user should create one himself)?
> 
>> Or maybe these tunables should be placed deeper, like:
> 
>> `tunables/<something>/usr.bin.thunderbird{,.d}`
> 
> At first glance I would essentially apply the same path structure as
> what we do for top-level profiles:
> 
>  * `tunables/usr.bin.thunderbird`, shipped by the package, has the
>    default settings
> 
>  * `local/tunables/usr.bin.thunderbird` can be used by the local admin
>    to override/extend the default settings
> 
> The thing is, I'd rather not ship yet another empty file that is
> strictly needed to parse/compile the usr.bin.thunderbird profile: as
> we've been discussing a few days ago, this would cause unnecessary
> packaging complexity, add painful coupling, and make us even more
> stuck into old-style filesystem conventions that are problematic for
> important use cases these days.
> 
> So this seems to be yet another use case for a directive like
> #include_if_exists (or #include -<path/to/snippet>, to reuse systemd
> conventions wrt. directives that are allowed to fail). I've had
> a quick look (disclaimer: I'm not a C person and know nothing about
> flex parsers) and it seems this should not be very hard to implement
> in parser/parser_lex.l. Maybe we could discuss the interface and
> behavior of this new/updated directive in a dedicated thread, and once
> we've reached an agreement I could try to find someone to implement it?
> 
yes very easy to implement, its mostly agreeing on the syntax