[snap] chrome-gnome-shell extension fails to detect native host connector

Bug #1741074 reported by Olivier Tilloy on 2018-01-03
456
This bug affects 90 people
Affects Status Importance Assigned to Milestone
chromium-browser (Ubuntu)
Medium
Unassigned
goopg (Ubuntu)
Undecided
Unassigned
kdeconnect (Ubuntu)
Undecided
Unassigned

Bug Description

Olivier Tilloy (osomon) wrote :
Olivier Tilloy (osomon) wrote :

stracing the snap reveals that /usr/bin/chrome-gnome-shell cannot be found in the context of the snap:

  15760 access("/usr/bin/chrome-gnome-shell", F_OK) = -1 ENOENT (No such file or directory)

This is not an apparmor denial. Inside the snap’s execution environment, /usr/bin is in fact /snap/core/current/usr/bin.

Emanuele (emanuc) wrote :

Is there any news about this bug?
To this day I still can't use plasma-browser-integration

Olivier Tilloy (osomon) wrote :

I've toyed with an unpacked example extension that talks to a native host connector (a simple python script that listens to messages and echoes all it receives).

This works with the following caveats:

 - the connector has to be installed under $SNAP_USER_DATA/.config/chromium/NativeMessagingHosts/

 - the path to the connector in the manifest needs to be an absolute path (as documented at https://developers.chrome.com/extensions/nativeMessaging), e.g.:
    "path": "/home/osomon/snap/chromium/current/.config/chromium/NativeMessagingHosts/native-messaging-example-host"

Olivier Tilloy (osomon) wrote :

chrome-gnome-shell wouldn't work like that unmodified, because the connector has external dependencies (it's a python3 script that imports GLib and Gio).

Olivier Tilloy (osomon) wrote :

Also, the connector talks to the org.gnome.Shell.Extensions D-Bus API, for which there doesn't exist a snapd interface, so one would need to be written, and I'm pretty sure it wouldn't qualify for auto-connection given the level of privilege it would expose (listing installed extensions, install and uninstall extensions).

Russ Dill (russ-dill) wrote :

This is really frustrating and 19.10 is coming up fast which I understand will switch everyone over to snap based chromium making extensions.gnome.org unusable for everyone. Any chance of switching back to non-snap based chromium if this issue isn't resolved before then?

Olivier Tilloy (osomon) wrote :

Unlikely. There are a number of higher priority issues with the chromium snap that we're focusing on now, and the plan to transition from the deb to the snap in 19.10 still holds.

I know this isn't a proper fix, merely a workaround, but you can use gnome-tweaks to manage your gnome-shell extensions.

zebul666 (zebul666) wrote :

How and why that snap has been rolled out in 19.10 while we have less feature with it ?

Note: I don't like snap.
This bug is another example why. Moreover nobody cares to fix this. If it is even possible...

Paul White (paulw2u) wrote :

zebul666, please take time to read:

https://discourse.ubuntu.com/t/intent-to-provide-chromium-as-a-snap-only/5987
https://discourse.ubuntu.com/t/please-test-chromium-snap-as-a-replacement-for-the-deb/7978
https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179

Those threads should answer your questions as to why the Chromium browser will only be provided as a snap in Ubuntu 19.10 and eventually in all supported releases of Ubuntu.

sbaragnaus (sbaragnaus) wrote :

This bug is still present in Kubuntu 19.10. Poor Chromium...

Proton Pony (protonpony) wrote :

Chromium is now incapable of managing extensions for Ubuntu's primary desktop environment? This issue is tolerable only because Google Chrome is not affected. Is Google somehow behind this apparent reluctance to remedy the problem?

Olivier Tilloy (osomon) wrote :

It's been reported that the GooPG extension doesn't work because it uses native messaging (https://discourse.ubuntu.com/t/call-for-testing-chromium-browser-deb-to-snap-transition/11179/207).

Coeur Noir (coeur-noir) wrote :

2020-01-06 : https://forum.ubuntu-fr.org/viewtopic.php?pid=22202596#p22202596

It seems still broken in not-yet-released ubuntu 20.04.

Avamander (avamander) wrote :

KDE Connect is also affected by this. I'm wondering though, unable to find the answer online, why was the transition to snap-based chromium made?

(I think) It makes development easier, you don't have to build it for every Ubuntu version in support, or any Linux OS, it contains specific libraries you know won't cause issues with the app.

Horst Baerbel (horstbaerbel) wrote :

I want to add this affects Firefox + the KeepassXC extension too. I agree that NativeMessaging is kind of a crutch, but if there is no way to make this work safely a snap interface needs to be implemented that applications from inside / outside of snap can use. There is demand for this kind of interface, so maybe devising a "correct" way of doing this and communicating it to the application / plugin developers would be a good thing...
At the moment I work around by installing firefox from repo and ignore the issue, but some day this might not work anymore. I'm kind of worried that I upgrade to Ubuntu 20.04 and Firefox is not available from repo anymore :/

Balazs Gyurak (ba32107) wrote :

Hi! Any update on this please? This is an extremely frustrating issue that makes me consider switching from Ubuntu to something else.

Alberto Donato (ack) wrote :

This is still an issue on 20.04

Jeffrey Bouter (jbouter) wrote :

This also affects the browserpass extension for the pass (passwordstore.org) password manager

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in goopg (Ubuntu):
status: New → Confirmed
Changed in kdeconnect (Ubuntu):
status: New → Confirmed
Ian Johnson (anonymouse67) wrote :

@osomon, could you point me to an existing forum post or start a new one summarizing what accesses would be necessary to manage gnome shell extensions? I couldn't find one searching, but if there's not one we should open one to try and discuss with snapd architects. Thanks

Olivier Tilloy (osomon) wrote :

@anonymouse67: see comments #2, #5, #6 and #7 in this bug.

Farab (farabf33) wrote :

This "connector" issue is also presents on firefox snap v77.0b2 (64-bit) Ubuntu 20.04 and has not addressed yet.

Bruce Crowther (bwucie) wrote :

Harrumph: not impressed. Was working fine this morning, then an update landed me with the snap version.

Back to gnome-tweaks...

Bruce Crowther (bwucie) wrote :

Nope, never mind gnome-tweaks. Removed Chromium snap and installed Google Chrome. Problem goes away.

Marcin (mwoz123) wrote :

Any changes on this bug (since 2018)? Maybe at least workaround?

I confirm same problem on Focal 20.04 LTS with snap Opera (chrome based)

Download firefox from its website, just run it from it's unzipped directory

Olivier Tilloy (osomon) wrote :

One suggestion discussed in https://forum.snapcraft.io/t/allow-classic-confinement-for-postman-agent/19228 is to use a content interface to allow third-party snaps to write to ~/snap/chromium/common/chromium/NativeMessagingHosts/. Whether it’s a good idea from a security perspective is open for discussion, and it wouldn't solve all the problems discussed here, but it could be part of the solution to enable third-party native host connectors.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.