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

store-requests
#1

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.

Screenshot from 2023-08-31 10-35-00
Screenshot from 2023-08-31 10-35-00902×308 24.1 KB

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:

3 Likes
#2

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.

#3

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

#4

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.

#5

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

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

  1. 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.
  2. 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?

1 Like
#6

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.

#7

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.

#8

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.

#9

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

#10

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.

2 Likes
#11

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

#12

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!

#13

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.

#14

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.

1 Like