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

Hi. I’m snapping a program that makes use of a native messaging host browser addon as an extra companion. For now the integration that is needed is with the non snap version of firefox… one step at a time :wink: I have the script in the snap with the binary that is called, and use the json file lo locate it, as the native messaging host is supposed to work (it’s really a mistery to me…but apparently this is it…). Can I use the personal-files interface to have my snap “own” this single file under the .mozilla/native-messaging-hosts/ directory?

1 Like

Note that granting this permission will allow sandbox escape.

As described in the spec, the json file looks something like this:

{
  "name": "ping_pong",
  "description": "Example host for native messaging",
  "path": "/path/to/native-messaging/app/ping_pong.py",
  "type": "stdio",
  "allowed_extensions": [ "ping_pong@example.org" ]
}

To start the native messaging host, the browser will run the executable specified by the path attribute.

If a strict confined snap can write such a file, it could set path to an executable within $SNAP. The browser would then start it without any confinement.

Right… so instead of the path to the executable within the snap I would need to set it to something like
/snap/bin/pingpong, but that would add a pingpong cli app…
Probably a “hidden” command could be useful, that can be accessed via a /snap/something/pingpong, but is not directly in PATH?
Is there a way to do this properly? Or is it something intended in the future?

Could this be a use for the interface hook?
If I connect to the personal-files interface, then my json file is copied to .mozilla/…
then if I disconnect it’ll be removed…

The application could be well behaved and set the path to /snap/bin/my-snap-command and have it launched with proper confinement. The problem is that it could just as easily specify some other path: the user would have to trust the snap to behave rather than the sandbox ensuring that the snap can’t misbehave.

With that said, we do grant classic confinement to snaps where it makes sense. That provides a similar level of access to the system, so I’m not saying your request should be denied outright. Just that it should probably be judged by this higher standard.

I’m trying to build a snap with the interface hook, as a proof of concept.
I set my hook declaration like this:

plugs:
  native-messaging-integration:
    interface: personal-files
    write:
    - $HOME/.mozilla/native-messaging-hosts/org.foo.json

hooks:
  interface:
    plugs:
      - native-messaging-integration

then in snap/hooks I added an interface file with a script:

#!/bin/sh -e

# mkdir -p /home/$USER/.mozilla/native-messaging-hosts/
cp /snap/jabref/current/lib/org.foo.json /home/$USER/.mozilla/native-messaging-hosts/

I can’t get it to copy the file…
I suppose the mkdir cannot work because I’d have to give permissions over the whole directory…
but still, if the dir exists it won’t copy the file on snap connect.
Am I missing something about how this works?

Hooks are run once system wide rather than once per user. The sandboxing also prevents the hook from accessing data associated with any specific user.

You could adjust things to install to the system wide location /usr/lib/mozilla/native-messaging-hosts. You’d need these changes:

  1. switch the plug to use system-files, and the write location to /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/org.foo.json
  2. Adjust the hook script to write to the above location.

The /var/lib/snapd/hostfs prefix is required to access the host’s root file system from within the sandbox.

Ah ok…the system-files interface would work! Good to know. I thought the interface one could work per user. It’s functionally the same in this case… is /var/lib/snapd/hostfs a prefix to /?

EDIT: I think you answered already to the last question :wink: Thanks

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.