How to expose desktop files created by snaps to the DE?

snapd
2

This is tricky because if the snap can arbitrarily write to anything in $XDG_DATA_DIRS, then it can escape confinement by creating a desktop file with a crafted Exec line. I’m not sure how to solve this, but it is clear that snapd needs to be involved to sanitize the desktop file. One idea might be snapd userd gain a ‘register desktop file’ DBus API that snaps could call (perhaps via a helper command in a similar manner as the xdg-settings ideas). This obviously requires that snaps be modified to use it.

3

Thanks for the analysis and suggestion @jdstrand. How do we go from there? Does this need to be discussed further, or can I file a feature request (if so in which form)?

4

I don’t see a clear path forward so I definitely think it needs to be discussed further and I think it might be interesting if someone did some investigation on the major browsers to see if there are any commonalities. Would need @niemeyer and @mvo to comment on a general direction at the very least.

5

As far as I know, firefox doesn’t expose such a webapp mode to allow users to create standalone shortcuts to their favourite websites.

1 Like
6

@niemeyer, @mvo: your opinion welcome on this topic (especially @jdstrand’s suggestion in the first comment).

7

I like that the Snap package of Chromium blocks access to my .ssh folder from the browser. The Flatpak “home” access still allows hidden file and folder access.

However, the lack of this “web app” feature is a blocker to me adopting the Snap version of Chromium. Most of the “apps” I use throughout the day are web apps. I use this Chromium feature to add them to my Gnome dock and switch between them frequently using Super-1, Super-5, etc.

Also, this feature is very natural to use on Chromebooks, so it’s appealing to Ubuntu users like me who switch back and forth between and Chromebook are trying to keep our the experience consistently.

I’ll try Flatpak and see if it offers this feature.

1 Like
8

@niemeyer, @mvo: can I kindly ask for your opinion here, on @jdstrand’s suggestion in the first comment?

This is potentially a problem that would deter users from using the chromium snap, and thus prevent us from fully migrating the deb to the snap.

1 Like
9

@pedronis can authoritatively weigh in on this as well.

10

We could have some userd API for this. It would be better if we were mediating a pre-existing or common interface though.

11

Ok, so what’s the next step here to ensure that this ends up on the snapd roadmap?

1 Like
12

it likely would have to be contributed (as other desktop features) with the snapd team reviewing.

13

@jamesh what do you think about @jdstrand’s suggestion?

14

It seems like a reasonable feature, and useful to more than just Chrome. Other (currently unconfined) examples I can see on my system include Wine creating desktop files for installed Windows apps, and Steam creating (optionally) creating desktop files for installed games. So it definitely seems like a

I have a few thoughts here:

  1. This might be a candidate for an xdg-desktop-portal API. If we make it snap specific, then we need to convince the upstream to carry a potentially invasive snap specific patch. That API may call out to userd or the session agent to complete the task when the client is a snap.
  2. The API would need to copy the desktop file plus dependencies somewhere the snap can not write to. This includes icons.
  3. We’d definitely need to implement image file validation for this. All the existing cases where we expose images from snaps to the host involve files distributed as part of the snap, which can be checked by review tools. For a feature like this, the app will usually want a new icon for each desktop file: presumably created in writeable storage. So snapd+tools would be the only line of defence in deciding whether the image file is malicious.
  4. Both Wine and Steam both install new icons to ~/.local/share/icons/hicolor for the new desktop files they create, potentially including multiple sizes. This should be a consideration in the shape of the API.
  5. If we use the snap’s existing desktop file as a template, what fields should it be allowed to replace? At a minimum, it probably needs to be:
    • Name
    • arguments to the Exec line
    • Icon
    • probably Comment
    • probably Categories
  6. We’d want some way to clean these files up when the snap is uninstalled. We’ve already got snapd poking around the users’ home directories on uninstall, so perhaps it could handle this too. Alternatively, it could be handed off to the session agent: either to handle immediately, or when the user next logs in.
15

a non-snapd specific API would also be my preference to be clear

1 Like
16

Some other thoughts:

  1. will any of these applications want to create desktop files with actions (i.e. additional [Desktop Action foo] sections with their own display name and command line)?

  2. do we care about translations? These additional desktop entries are created per-user, so perhaps the app can just produce strings in the user’s native language from the start. This appears to be what Wine and Steam do (or perhaps they just produce English up front?).

  3. this one is probably Chrome specific: does the application want to register mime types as being handled by the new desktop file? I know there is a navigator.registerProtocolHandler web API, so does Chrome do anything to a webapp’s desktop file if this gets called? Does that mean it might want to modify the desktop file after it has been created?

17

Chromium does that too.

Not chromium, as far as I can tell.

Again, as far as chromium is concerned, no. The only user-facing string in the desktop files that it creates is the Name key, and the user is allowed to modify it at creation time.

No. See the relevant code in chromium. No MimeType key.

18

Note that chromium attempts to call the xdg-desktop-menu utility to install the generated desktop file.
This obviously fails in a strictly confined snap.

1 Like
19

And for reference, this is how a desktop file generated by chromium looks like (note that the Exec line is incorrect as it points to the chromium binary, and would result in it being run unconfined):

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Snapcraft forum
Exec=/snap/chromium/887/usr/lib/chromium-browser/chrome --profile-directory=Default --app-id=fadliobngcdalcjhmgmngaocgindcomi
Icon=chrome-fadliobngcdalcjhmgmngaocgindcomi-Default
StartupWMClass=crx_fadliobngcdalcjhmgmngaocgindcomi
20

I tried manually fixing the paths and putting the file in ~/.local/share/applications, but I end up with a generic icon and all such apps gets grouped together under a single icon instead of appearing individually.

This is an essential feature for me, so I’m giving on the Chromium snap until this bug is fixed (or I find a workaround)

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Telegram
Exec=/usr/bin/snap run chromium "--profile-directory=Profile 1" --app-id=clhhggbfdinjmjhajaheehoeibfljjno
Icon=chrome-clhhggbfdinjmjhajaheehoeibfljjno-Profile_1
StartupWMClass=crx_clhhggbfdinjmjhajaheehoeibfljjno
21

Out of curiosity, if you replace “/usr/bin/snap run chromium” by “/snap/bin/chromium” in the Exec line, does it make a difference wrt grouping apps in the launcher?