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


#1

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?


System-files permission for jabref (native-messaging-hosts integration)
#2

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.


#3

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?


#4

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…


#5

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.


#6

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?


#7

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.


#8

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


#9

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:


#10

I got it to work!!
Thanks for the support


#11

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/).


#12

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.


System-files permission for jabref (native-messaging-hosts integration)
#13

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