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
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
