On 2019-01-07 13:30, Ian Jackson wrote:
Vincas, thanks for reporting this bug on the debian-i18n list.
I think it needs a much higher profile.
We already have AppArmor bug [0].
Intention of debian-i18n is to figure is it possible to "automate" translation upon
AppArmor/language installation.
The problem is that on my machine, "Desktop" is actually "Darbastalis",
I think you mean "in your account" ? I mean, if you had several users
who used different languages, wouldn't their "Desktop" directory be
called different things ?
I do not know when these XDG dirs are "translated". If I choose Lithuanian language upon Debian
desktop installation, I get Lithuanian "Darbastalis". So I assume it's default based on "system
language", if that's ever a thing?
I do see that KDE settings allows user can select completely different "Desktop" directory. That
would be kinda out of scope, as that would need some sort of AppArmor helper and kernel variables to
change these "on the fly". This is "over my head", so we should ask AppArmor developers to comment
this...
My intent is to somehow translate "official" Desktop "names".
```
@{XDG_DESKTOP_DIR}+="Darbastalis" #lt
@{XDG_DESKTOP_DIR}+="Darbvirsma" #lv
@{XDG_DOWNLOAD_DIR}+="Atsisiuntimai" #lt
@{XDG_DOWNLOAD_DIR}+="Lejupielādes" #lv
...
```
These are interesting ideas. I don't know enough to say if they would
work.
Yes, appending variable "value list" works, I've been testing by modifying
`/etc/apparmor.d/tunables/xdg-user-dirs.d/site.local` file:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883948#25
My idea was maybe it is possible to "translate on the installation", based on *available* languages
in the system, instead of pre-translating "Desktops" into all known languages and ship (by upstream
itself) a big fat `/etc/apparmor.d/tunables/xdg-user-dirs` file. Not sure what would be performance
hit by having such a variables containing all known "Desktops" and "Downloads, etc, for AppArmor
kernel module to perform matching.
Though I am not sure how that could be achieved, hence I ask this
list for guidance.
I think this requires some technical input from the AppArmor folks.
I see you CC'd the uploader already but I think this is a bug and
should be tracked in the Debian BTS.
Again, [0].
I have set the bug to `serious' because of this impact as described by
Vincas:
if AppArmor profile for application "Foo" defines rule
`@{XDG_DESKTOP_DIR}/** r,` to allow reading from desktop, it will
not work for my localized desktop directory name.
That is phrased hypothetically but I imagine it is common. That kind
of thing is after all what these rules are there fore.
The reality is that profiles that ship in distributions are rather.. permissive, like, allowing to
access all $HOME (except sensitive dot files & directories of course) in order not to break user
experience too much. For example, from Thunderbird's profile [1]:
```
# rw access to HOME is useful when sending/receiving attachments
owner @{HOME}/[^.]** rw,
```
Or LibreOffice [2]:
```
@{libo_user_dirs} = @{HOME} /mnt /media
...
owner @{libo_user_dirs}/**.@{libreoffice_ext} rwk, #Open files rw with the
right exts
```
Or Totem [3]:
```
# Allow read and write on almost anything in @{HOME}. Lenient, but
# private-files-strict is in effect.
#include <abstractions/private-files-strict>
owner @{HOME}/[^.]* rw,
```
Of course, it would be nice if GUI application would only allow (let's say) Downloads and Desktop to
be accessible by default, and allow strict-full (no dot files & dirs) if users choose so, by
enabling "less permissive mode" *somewhere* (by some GUI configurator, etc), but that would needs
AppArmor tooling, "helpers", etc...
Well, there is `aa-update-browser` utility (in apparmor-utils) that can be used in Ubuntu (as it
ships Firefox profile, although disabled by default) to select how strict AA policy of Firefox is.
If there would be similar tooling to configure (in user-friendly way, not by fiddling with AA
profiles) arbitrary application profile, then these XDG_XYZ_DIR's would be much more helpful.
To the AppArmor maintainers:
I have filed this as `serious' not to try to force you to fix this,
but because this bug seems like it will cause AppArmor to work badly
for many people and I felt you would want me to be sure you noticed.
So please adjust the severity as you like.
Since these variables are note really looks "interesting" in current AppArmor state, I doubt this
bug should be marked as "serious". More like a feature request to be useful in the future.
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883948
[1]
https://gitlab.com/apparmor/apparmor-profiles/blob/c69719d970a5ae96835b01b165ca19a1b2da2c42/ubuntu/19.04/usr.bin.thunderbird#L80
[2]
https://cgit.freedesktop.org/libreoffice/core/tree/sysui/desktop/apparmor/program.soffice.bin?id=3272c1eb5563f3bda2caa24f32b1018372622109#n103
[3]
https://gitlab.com/apparmor/apparmor-profiles/blob/c69719d970a5ae96835b01b165ca19a1b2da2c42/ubuntu/19.04/usr.bin.totem#L36
