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