On 2017-12-04 19:53, John Johansen wrote:
On 12/03/2017 04:05 AM, intrigeri wrote:
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
Oh, I missed that part. So we move variables from
apparmor.d/usr.bin.thunderbird into that file then?
And that particular file would includ local/tunables-one?
I actually see this a little too complicated. Imagine moving these bunch of Libreoffice variable definitions away from
main profile. Policy kinda becomes two-part profile in the sense, a little harder to grasp maybe. Although I agree that
would be kinda systematic approach.
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
John, what's your view about using variable-include-file-as-extension-point in
the dawn of the per-user policy files?
Maybe this proposition will become redundant in some sence? How would variables usage would play in the policy
namespaces use case? Will there be sort of $HOME/.config/apparmor/tunables/usr.bin.thunderbird ?
--
AppArmor mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
