Request for personal-files interface in Chromium for ~/.local/share/applications

nteodosio · August 31, 2023, 8:50am

Chromium supports progressive web applications (PWA). For example, if you log in to chat.google.com, you can install the web app by clicking the corresponding icon in the URL bar.

This installs the app as if it were a system app, so it can be displayed on the dock and be found in the activities menu.

That happens by writing a *.desktop file to either /usr/share/applications or ~/.local/share/applications. An example of such file that Chromium installs is

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=Google Chat
Exec=/snap/bin/chromium --profile-directory=Default --app-id=mdpkiolbdkhdjpekfbkbmhigcaggjagi
Icon=chrome-mdpkiolbdkhdjpekfbkbmhigcaggjagi-Default
StartupWMClass=crx_mdpkiolbdkhdjpekfbkbmhigcaggjagi

Desktop environments obviously do not look for those in each ~/snap/* directory but that’s where Chromium can and does write them.

As such, to make PWA work for users of the snap, I would need it to connect to personal-files so that it is able to write and read from ~/.local/share/applications.

Links:

kenvandine · August 31, 2023, 1:18pm

I’m a +1 on this, but it would be better to name it dot-local-share-applications to make it clear what it’s accessing. I know there’s already a personal-files interface that doesn’t match that pattern in that snap, but that probably predates this standard naming agreement.

nteodosio · August 31, 2023, 2:55pm

Sure, I’m renaming it dot-local-share-applications.

alexmurray · September 1, 2023, 1:21am

Hmm I am not sure it would be a good idea to grant this - allowing write access to ~/.local/share/applications allows a trivial sandbox escape for chromium since it can just drop a new desktop file there that overrides the one installed by snapd which launches itself (or some other application) outside of the regular confinement provided by snapd.

Assuming we trust chromium that perhaps is ok BUT it doesn’t account for the case where chromium gets remotely exploited and an attacker uses this to then escape the sandbox.

Unfortunately I think this would need support from snapd to allow it to proxy and enforce the desktop files were created with appropriate values that do not allow sandbox escape. @jamesh I wonder if the desktop team has thoughts on this? (similarly @pedronis whether you have any thoughts). Thanks.

jamesh · September 1, 2023, 2:10am

So there has been work on the xdg-desktop-portal side to try and solve this problem here:

github.com/flatpak/xdg-desktop-portal

Dynamic Launcher Portal design questions

opened 09:59PM - 21 Dec 21 UTC

closed 08:38PM - 17 Mar 22 UTC

mwleeds

new portals

Context: https://gitlab.gnome.org/Teams/Design/os-mockups/-/issues/144 This i…ssue is for discussing the technical architecture of a new portal that would allow sandboxed applications to install `.desktop` files and icons used by those desktop files to make launcher entries in the desktop environment's application launcher. The primary use case for the portal is to allow Epiphany or Chromium to install web apps when running under Flatpak (or Snap). However it could have other use cases. cc @matthiasclasen ## Requirements - Sandboxed applications should be able to request installation of a launcher, resulting in a dialog where the user can see the name and icon, and in the case of web apps the URL. Depending on the options used by the calling application, the user can edit the name (Chromium would not allow this). The sandboxed application can then use the name returned by the portal and other information to create a `.desktop` file which it would pass to the portal. The portal would rewrite the `Exec` line to prepend it with `/usr/bin/flatpak run com.example.App` using the app ID of the calling app. This ensures that (a) the user is consenting to the sandboxed application installing the launcher and (b) the launcher is only able to run binaries in the same sandbox as the app. The portal would then install the `.desktop` file and icon file to locations in $XDG_DATA_DIRS which are not writable to the sandboxed app (unless that permission was specifically granted). - The portal could also be used by unsandboxed applications. This makes sense so that Epiphany can use the same code path when installing web apps rather than maintaining two code paths that do the same thing. - For the initial implementation the portal does not need to allow the launcher to be edited after being installed. Epiphany currently allows editing the name or icon of installed web apps, and apps may also want to update their own name or icon for example if their logo changes, but this could be left out of the MVP. - There also needs to be a mode where the portal allows the installation of a `.desktop` launcher by a sandboxed application without any user interaction, but only if a token (a UUID string) is provided which was previously obtained by an unsandboxed trusted system component. This is necessary so that GNOME Software can install web apps without requiring user interaction beyond clicking the "Install" button. GNOME Software would talk to Epiphany over D-Bus and provide the token acquired from the portal, so that Epiphany can stay in charge of the on-disk format for its web apps. - The portal also needs to allow deleting launchers. For sandboxed applications we could only allow deletion of launchers installed by that application so that the portal doesn't need to do any user interaction. ## Open questions - Is the interface in the right shape? - Is it correct to only have the `PrepareInstall()` method use the `org.freedesktop.portal.Request::Response` pattern, since it is the only one that involves waiting on user interaction? - How should the icons be passed around? Generally portals pass files using document IDs or file descriptors as documented in the [README](https://github.com/flatpak/xdg-desktop-portal/blob/master/README.md). For the `RequestInstallToken()` method the caller is not sandboxed, so should it still pass an fd rather than a file path? The path could be simpler to store along with the generated token in the portal's own storage, whereas it's unclear to me if an fd would necessarily stay open until the `Install()` method call when it's needed. The `PrepareInstall()` method is for sandboxed use so if Epiphany is initiating the install, it can write the icon to a directory in its writable area, `~/.var/app/org.gnome.Epiphany/cache/` and pass the fd to prove it has access. - Is the scheme laid out in the description of the `Uninstall()` method acceptable, where there would be a subdirectory of `~/.local/share/applications/` with a name that can be owned on D-Bus by the sandboxed application, for the desktop files? For example Epiphany needs `--own-name=org.gnome.Epiphany.*` in its Flatpak `finish-args` to be able to launch its installed web apps so we could check for that to validate that the prefix `org.gnome.Epiphany.WebApp-` can be used by Epiphany, even devel or canary builds that have app IDs `org.gnome.Epiphany.Devel` / `org.gnome.Epiphany.Canary`. - What should the directory holding the icons be called, `~/.local/share/icons_org.gnome.Epiphany.WebApp/`? The icons would need to live somewhere not writable to the sandboxed application so they have to be moved somewhere by the portal. - How do I proceed with designing the `org.freedesktop.impl.portal.DynamicLauncher` interface? I understand that's what a backend like `xdg-desktop-portal-gnome` will implement? ## Proposed interface: <details><summary>org.freedesktop.portal.DynamicLauncher.xml</summary> ```<?xml version="1.0"?>  <node name="/" xmlns:doc="http://www.freedesktop.org/dbus/1.0/doc.dtd">  <interface name="org.freedesktop.portal.DynamicLauncher">  <method name="Install"> <arg type="s" name="token" direction="in"/> <arg type="s" name="desktop_file_id" direction="in"/> <arg type="s" name="desktop_entry" direction="in"/> <arg type="a{sv}" name="options" direction="in"/> <arg type="u" name="result" direction="out"/> </method>  <method name="PrepareInstall"> <annotation name="org.gtk.GDBus.C.UnixFD" value="true"/> <arg type="s" name="parent_window" direction="in"/> <arg type="s" name="title" direction="in"/> <arg type="s" name="name" direction="in"/> <arg type="h" name="icon_fd" direction="in"/> <arg type="a{sv}" name="options" direction="in"/> <arg type="o" name="handle" direction="out"/> </method>  <method name="RequestInstallToken"> <arg type="s" name="icon_path" direction="in"/> <arg type="s" name="name" direction="in"/> <arg type="a{sv}" name="options" direction="in"/> <arg type="s" name="token" direction="out"/> </method>  <method name="Uninstall"> <arg type="s" name="desktop_file_id" direction="in"/> <arg type="a{sv}" name="options" direction="in"/> <arg type="u" name="result" direction="out"/> </method> <property name="version" type="u" access="read"/> </interface> </node> ``` </details>

https://github.com/flatpak/xdg-desktop-portal/pull/696

This likely doesn’t solve the immediate request here though:

I strongly suspect that we might need to do some snap enablement for the portal. This doesn’t seem like the kind of thing where work to enable it for Flatpaks will carry over.
The sandboxed app needs to know how to use the portal API.

While I think the above is where we eventually want to get to, it might still be worth considering the proposal in this thread as an intermediate solution. Part of the trade off is that not providing PWA launchers may encourage people to use browsers completely outside of our ecosystem, where we have no control over security.

On the proposal itself, I see this in the generated desktop file:

This is a named icon that Chromium has presumably written to ~/.local/share/icons. Do you need that access as well?

nteodosio · September 1, 2023, 7:01am

Yes, that often happens as the linked bugs reports show. People switch to Chrome or invoke the unconfined binary (/snap/chromium/current/usr/lib/chromium-browser/chrome) itself. Actually, up until now Chromium itself put that as the Exec path, so even those who copied the file over from ~/snap/chromium/… to ~/.local/share/applications would be unknowingly escaping the sandbox.

This is a named icon that Chromium has presumably written to ~/.local/share/icons. Do you need that access as well?

Actually yes, thanks for pointing it out, I overlooked that as I in the further past had moved the icon manually.

dclane · September 5, 2023, 1:09pm

I am conflicted on this one because I agree with @alexmurray about the sandbox escape this enables, but if the alternative is users bypassing it by either switching to an unconfined browser, or invoking chromium in an unconfined way, then they’re no better off.

I would love to vote no, but I find myself leaning towards +1’ing this until there is a usable alternate.

dclane · September 12, 2023, 2:17pm

From a quick couple of tests, it looks like the Exec line is always Exec=/snap/bin/chromium [...] (confined) which is good at least. @nteodosio are you able to confirm that’s always the case with the chromium snap, or do PWA developers get to define that? I figure not, as that would hardly be cross platform but just want to be sure in my understanding.

nteodosio · September 12, 2023, 2:35pm

That is correct. PWA developers have no say whatsoever over that.

James-Carroll · September 12, 2023, 3:13pm

I wouldn’t consider this important for the 99.9% of use cases, but if the user were to use parallel installations of Chromium, you wouldn’t be able to generally assume that /snap/bin/chromium was correct, it could be e.g /snap/bin/chromium_beta or /snap/bin/chromium_imreallyuncreativewithnames

But I’m just being pedantic here, since the vast majority of people wouldn’t be running into that I imagine, yet browsers seem like an ideal candidate for parallel installations generally, so it could be worth considering if easily accomodatable.

nteodosio · September 12, 2023, 5:01pm

Nice reminder, that’s actually already the case, the snap is using /snap/bin/$SNAP_INSTANCE_NAME.

dclane · September 13, 2023, 1:38am

Ok the vote tally then stands at 2 votes for and 1 (initially) against, and it has also been discussed separately with @pedronis who did not object in this case so we will grant it. Long term, we must look at better use of the portal mechanism though.

A note on your yaml, you can drop the read element for desktop-files as write implies read. Could you also rename the interface from desktop-files to dot-local-share-applications to be consistent the naming convention for personal-files. You’ll have to add a dot-local-share-icons interface too.

Once these appear, I will grant their use in the store. Thanks!

nteodosio · September 18, 2023, 1:39pm

Thanks for the reviews.

Can I gently nudge a store master to approve 2627 and 2628? They await manual review and are holding several other releases already.

dclane · September 19, 2023, 5:14pm

Apologies for the delay @nteodosio, there was an issue with reviewtools that we had to work through today. We are manually releasing each revision of Chromium for the time being. We will continue to do this until reviewtools is updated.