[apparmor] [RFC] How should we deal with /tmp/xauth* ?

[Vincas Dargis]

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 .