On 7/25/18 7:39 PM, Jamie Strandboge wrote:
On Wed, 2018-07-25 at 19:22 +0300, Vincas Dargis wrote:
It could, but that's gamble against name clashing with some package
installed in the future. Idea
with env.d is that it should be populated only by packages.
I just looked in home.d and was reminded that there is a site.local
file there that is shipped by the apparmor package. Rather than adding
another location, apparmor upstream could ship something similar in
env.d and that would be in the apparmor package (and thus avoid
conflicts).
Hm, good point.
Let's see some combinations:
1. `/etc/apparmor.d/usr.bin.thunderbird` rules currently can be appended by using
`/etc/apparmor.d/local/usr.bin.thunderbird`.
2. Imagine that Thunderbird ships `/etc/apparmor.d/tunables/usr.bin.thunderbird`, then user could
modify Thunderbird-related tunables via `/etc/apparmor.d/local/tunables/usr.bin.thunderbird` (user
could change profile directory when needed [0])?
I doubt we would ask package maintainers to also ship
`/etc/apparmor.d/tunables/usr.bin.thunderbird.d` directory *and* `site.local` file within it for
local modification, especially as we have `#include if exists`. Since some Thunderbird addon could
actually ship `/etc/apparmor.d/tunables/usr.bin.thunderbird.d/lightning` (or similar) file, so we
would need that distinct `site.local` (or similar) for local modifications too.
Using conditionally-included `local/tunables` would be consistent with 1. use case, and less files
to ship for maintainers.
3. AppArmor default variables are shipped in /etc/apparmor.d/tunables/x and can be modified by local
administrator by modifying /etc/apparmor.d/tunables/x.d/site.local.
This is kinda "different", inconsistent from `local/` usage for altering profiles and their
tunables. Although, if `site.local` are shipped already we can just keep using this scheme I guess.
It's also kinda self-documenting.
Or.. we could start slowly conditionally-including `local/tunables/home` and friends, keeping
site.local only for compatibility, legacy modifications :) . site.local could be dropped by package
upgrade if it's not modified by the user at some point, achieving less files needed to be shipped,
and some more consistency.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882218 .
--
AppArmor mailing list
AppArmor@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/apparmor
