snapd
snapd copied to clipboard
interfaces: give priority to desktop-launch over desktop-legacy
The interface 'desktop-legacy' (and 'unity7') specifically denies read access to the .desktop files, which means that any extension that requires it (like gnome or kde) won't be able to read them.
Unfortunately, there are some specific cases where reading the .desktop files is mandatory, like when implementing the new Refresh Awareness specification. This specification requires to show the "visible name" of a snap, and its icon, and in order to have access to that, it is mandatory to be able to read the .desktop files.
The 'desktop-launch' interface does include read access to the .desktop files. Although it is a very privileged interface, it is not a problem because the snaps that implement the Refresh Awareness specification are too, so using it to gain access to the .desktop files should be enough. Unfortunately, mixing it with 'desktop-legacy' interface (which happens when the snap implementing the Refresh Awareness specification also uses the gnome or the kde extension) results in not having access to the files, because the 'deny' rules set by the later have priority over any 'allow' rule set by the former.
This PR adds a check when adding the specific .desktop rules in the 'desktop-legacy' interface: if the snap has a plug for the 'desktop-launch' interface, it won't apply the .desktop rules. This is not a problem, because without them, no access is granted by default (the rules added by 'desktop-legacy' allow to list the .desktop files, but not read them).
Thanks for helping us make a better snapd! Have you signed the license agreement and read the contribution guide?
Another possibility would be to create an specific interface to allow to read .desktop files, and give it priority instead of "desktop-launch".
The big problem is that using the gnome extension forces the use of desktop-legacy, which forces being able to read the list of files in the applications
folder and not being able to read the data in those files. It seems to be done to avoid noise in the journal when XDG libraries try to read the .desktop files, according to interfaces/builtin/utils.go
-> getDesktopFileRules()
.
I have to say that, yes, this approach is a bit "unorthodox" and "ugly", so maybe another way could be to add an specific API call, allowed only if the desktop-launch
interface is connected, that allows to read .desktop files if the path is known... I can do a PR proposal... or maybe a document proposal... what do you think?
marking blocked just because I'm asking previous reviewers to review the new test
Got go-ahead from @sergio-costas to merge