snapd icon indicating copy to clipboard operation
snapd copied to clipboard

interfaces: give priority to desktop-launch over desktop-legacy

Open sergio-costas opened this issue 9 months ago • 2 comments

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?

sergio-costas avatar May 03 '24 11:05 sergio-costas

Another possibility would be to create an specific interface to allow to read .desktop files, and give it priority instead of "desktop-launch".

sergio-costas avatar May 03 '24 13:05 sergio-costas

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().

sergio-costas avatar May 07 '24 11:05 sergio-costas

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?

sergio-costas avatar May 23 '24 08:05 sergio-costas

marking blocked just because I'm asking previous reviewers to review the new test

pedronis avatar Jun 05 '24 11:06 pedronis

Got go-ahead from @sergio-costas to merge

ernestl avatar Jul 01 '24 14:07 ernestl