System-files under .mozilla/native-messaging-hosts

I must be doing something wrong, because it’s not copying any file over.
The rest of the app works…
This is the snap yaml:

I got it to work!!
Thanks for the support

2 Likes

Now, we got it to work. Not sure how the “Manual review” works. Is there something triggerd on spacraft’s side (Refs https://dashboard.snapcraft.io/snaps/jabref/revisions/551/feedback/).

Since this has now moved to a request for system-files access can the topic of this request post please be updated accordingly so that it is clear exactly what is being requested?

Rather than having a snap need have to have write access to this location on the host system and install a file via a hook etc, instead ideally there would be an interface which allows snaps to use this in a more controlled manner, and which ensures that the resulting native-messaging file only specifies launching a binary within the snap, under-confinement etc.

However, until such an interface exists, +1 from me for granting write access to system-files as requested.

Thanks!
I intended this to be superseded by System-files permission for jabref (native-messaging-hosts integration)
Which is a “proper” request. That’s why I didn’t change anything in this conversation.

EDIT: The reason why the system-files permission is needed is explained here as well, so this can be used.
I changed the post topic
I agree that an interface would be better, but for the time being this seems to be the most user friendly way to address this issue

@alexmurray @jamesh This connection has been rejected in System-files permission for jabref (native-messaging-hosts integration)
Is there something that can be done to update the request?

+1 to allow installation of, but not auto-connection of system-files provided that the snap.yaml uses:

plugs:
  hostfs-mozilla-native-messaging-jabref:
    interface: system-files
    write:
    - /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/org.jabref.jabref.json

That said, I’m not tallying the votes since this allows sandbox escape so I think that @advocacy should vet the publisher and @pedronis should comment on the approach.

The name should not be an issue, we had selected something that was easier for users to identify,
if we were to tell them to snap connect jabref:browser-extension it seemed more user friendly, but it can be changed.
Non autoconnect is fine as well.
We are now testing other browser integrations (not fully implemented yet) for chromium browsers (chrome and non snap chromium, opera, brave, and the like…)
There are a couple of paths that are needed. Mostly they rely on the chrome path and the chromium path.
Would it be sensible to add two plugs to the location of native-messaging-host for chrome and chromium (possibly in different plugs, so one can be selected at a time?)
So from your example
hostfs-chrome-native-messaging-jabref:
/etc/opt/chrome/native-messaging-hosts/org.jabref.jabref.json
and
hostfs-chromium-native-messaging-jabref:
/etc/chromium/native-messaging-hosts/org.jabref.jabref.json.
That would be in another request once the implementation fully works, but since we’re working on it I was wondering if the same approach can be used.
The main concern would be having to ask the user to activate more than one, but that shouldn’t be too big of an issue, if it’s not possible to have a single permission.
And these can always be activated from gnome-software, right?
Thanks

Is there any news from @advocacy?
@pedronis @jdstrand

Ping @advocacy and @pedronis re @jdstrand’s comment above

FYI, @pedronis and I discussed this in Vancouver. It is unfortunate that while does not need classic to install since it can use system-files to install itself into the target browser, it will end up running outside of confinement since the plugin executes within the browser context. That said, browsers like firefox and chromium internally run extensions with different privilege levels than the rest of the browser.

Looking at the browser snap case (eg, firefox, chromium, etc) these browser snaps could expose their native-messaging-hosts directory via the content interface, for snaps like jabref to connect and place files. While this plugin mechanism is not currently implemented, it is well understood.

For now, we are prepared to grant jabref use of the system-files interface in the prescribed manner with the understanding that this is the equivalent of classic. @LyzardKing, I suggest working with mozilla for firefox and @oSoMon for the chromium snap on how they might provide native-messaging-hosts via the content interface for your snap to plugs.

Yes, that seems reasonable to me. Though keep in mind, there is the chromium snap as well, which is going to the primary means to consume chromium on Ubuntu.

For your specific use case, I think you would have:

plugs:
  hostfs-mozilla-native-messaging-jabref:
    interface: system-files
    write:
    - /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/org.jabref.jabref.json
  hostfs-chrome-native-messaging-jabref:
    interface: system-files
    write:
    - /etc/opt/chrome/native-messaging-hosts/org.jabref.jabref.json
  hostfs-chromium-native-messaging-jabref:
    interface: system-files
    write:
    - /etc/chromium/native-messaging-hosts/org.jabref.jabref.json

In this manner, users can snap connect to the browser of their choice.

@advocacy - can you please perform the vetting?

Thanks @jdstrand, and sorry if I insisted :wink:
I agree that the better solution would be to have an path exposed via the content interface.
This could also be used by the gnome extentions addon, since I believe that uses native messaging as well.
Regarding non snapped browsers only the native script would be run outside the confinement.
It then calls the jabref program like if it was run from the command line, so with the selected confinement.
But I understand your point.

The only question I have is: should I use /var/lib/snapd/hostfs on the /etc path as well?

/etc from the host is exposed directly to your snap’s runtime so the hostfs prefix isn’t needed there.

I may have been a little terse in my summary from yesterday. The use of system-files being discussed here allows for sandbox escape because there is nothing preventing the snap from not invoking via /snap/bin. Part of the agreement for allowing you use of the interface in this manner (and why we are performing publisher vetting) is that lib/native-messaging-host/firefox/org.jabref.jabref.json will use /snap/bin/jabref.<something> and thus register something that will run under confinement and not undermine the security properties of confinement.

In the browser snap/content interface scenario, the json file you register would need to point to something else you are giving to the browser snap’s provided content slot, and thus executing under the confinement of the browser.

You’re right…
I already added a jabref.browser-proxy app in the snap
I had forgotten about it.
The script runs confined as well

1 Like

@advocacy - can someone please perform the vetting?

1 Like

@advocacy - re-ping to perform the required vetting.

1 Like

@advocacy - can someone please perform the vetting? It looks like upstream is also interested in this snap: System-files permission for jabref (native-messaging-hosts integration)