[pkg-apparmor] Bug#883948: apparmor: xdg-user-dirs should have localized directory names

[intrigeri]

Control: severity -1 minor
Control: tag -1 + upstream
Control: forcemerge -1 918548

Rationale for the metadata changes:

 - This bug is about a given proposed solution to a broad class
   of problems.   

 - Bumping severity to minor, as the lack of a solution to this
   problem may lead to writing policy that's more relaxed than it
   could be, so let's call this >> wishlist (I'm curious about
   practical examples though: in practice, users expect to be allowed
   to read & save files wherever DAC allows them to; I doubt there's
   actual profiles in Debian that we would dare make stricter by
   default, even once this problem is solved). Not more than minor,
   for reasons explained there: https://bugs.debian.org/918548#25

 - Tagging "upstream", as a designing a good solution requires
   cross-distro discussion to get the interfaces right; and I would be
   a good solution will have an upstream component.

All in all, I'm not convinced the cost/benefit of making the
@{XDG_*_DIR} tunables translatable is particularly interesting.
One can't expect users to write their documents in XDG_DOCUMENTS_DIR,
nor to store their music in XDG_MUSIC_DIR: doing so is certainly
convenient when using a modern full-blown desktop environment, but
(thankfully!) humans are much more creative than that.

So I'd personally rather zoom out a bit and consider the more general
problem of "it's hard to predict at policy writing time where the user
will want to read/write files from/to". For some part of this problem
(when explicit user interaction is needed anyway), well known
solutions exist, for example the security by designation design
pattern, as implemented in Portals. For other parts of this problem,
e.g. "my music player should be allowed to read all my music files",
other solutions are needed; but I don't think that translating the
@{XDG_*_DIR} AppArmor tunables is one of them (too bad, because as
Jamie said, that seems pretty doable).

I've intentionally postponed this problem during the Buster cycle, as
a way to make "AppArmor enabled by default in Debian" tractable.
This has lead to making some of our policy super relaxed, and to
disabling some profiles by default. But I plan to tackle some of them
post-Buster, some of it in AppArmor upstream, some of it in Debian,
and probably some of it in other relevant upstreams.