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
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.
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.
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.
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:
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?
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.
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.
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.
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.
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!
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.
