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

Dear @reviewers,

I would like request a permission for system-files for the JabRef snap to access the /usr/lib/mozilla/native-messaging-hosts/org.jabref.jabref.json file.

Read access is needed for the firefox extention JabFox to find the native messaging host script as per https://wiki.mozilla.org/WebExtensions/Native_Messaging.

This has been discussed in Personal-file under .mozilla/native-messaging-hosts

Thanks in advance!
Galileo

Jabref - https://github.com/JabRef/jabref
snapcraft yaml - https://github.com/JabRef/jabref/blob/master/snap/snapcraft.yaml

This file is not present within the snap’s runtime and must be shipped by the snap itself. You may be interested in the Snap layouts feature so you can ship something in $SNAP in a manner that it appears at /usr/lib/mozilla/native-messaging-hosts/org.jabref.jabref.json within the snap.

As discussed in System-files under .mozilla/native-messaging-hosts I added a hook to copy the file to the system. The snap layouts would not make the file available to the browser, so I’m not sure how that would work.
There has been one vote on System-files under .mozilla/native-messaging-hosts, so it might be better to close this to avoid confusion.

EDIT: The other post is more clear about the necessary connections.
The file is in the snap and needs to be copied in /usr/lib/mozilla/native-messaging-hosts to be read by Firefox.

@jdstrand Let me know if the previous post is better suited to host the voting, or if there is something else that needs explaining

As discussed in the other thread, this is not something that layouts could help with: the idea is to make this file available to an unconfined Firefox instance running on the host.

Also discussed on that thread: this should be scruitinised similar to a request for classic confinement: by letting the snap write to this location in its configure hook, it can cause Firefox to run an arbitrary command (assuming the user has installed a matching extension). The safest solution would be to have a new interface type or wrapper generator, but absent that this seemed like a (slightly) safer option than classic confinement.

Sorry, I misread (actually I responded before reading the other thread) that this wanted to use files in /usr not put them there.

@pedronis - this is a new use case. In essence, the snap wants to put a file into /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/. This file extends firefox to launch a command and thus provides sandbox escape. It also doesn’t work with the firefox snap and possibly not cross-distro. As we are discussing in Synchrorep need classic confinement, this is a variation on extending the host’s software via its plugin/extension mechanism. Interestingly about this use case is that the snap doesn’t need classic since it is using system-files with hostfs (it is conceivable we could employ this methodology elsewhere, but see above about sandbox escape).

It was said that the snap could put a file in the hostfs which causes firefox to launch the extension under snap confinement which means that for system-files request with hostfs, we could add a proviso that the snap publisher must do this and the publisher must be vetted (since, like with classic, the publisher must be trusted to dtrt). While that potentially addresses the security aspect, it does not address cross-distro wrt paths or working with browser snaps.

No problem! It’s my fault for not being clear on the other thread :slight_smile:
What would be the cross distro issue in this case?
The file is being copied in the folder identified by upstream (firefox) documentation, so the location of the files should be correct.
I’m working on changing the file (the json) to call the script not directly but as a snap “app” declared in the snapcraft.yaml, so it should not escape the confinement.
As for snap browsers, that will need a different method (a connection ad-hoc?) for some acceptable integrations, as expressed in the synchrorep thread

If I update the snapcraft yaml, will that invalidate this request?

No. The reviewers and architect (@pedronis) are still discussing this and haven’t voted yet. Please adjust as you see fit and we can make sure a vote is on your latest changes.

Ok, So I’ll upload now a fix that keeps everything running in the contained snap environment
(except the json, but that executes /snap/bin/jabref.browser-proxy)

Does Fedora still keep the snaps in a different tree?
That might be an issue with cross distro compatibility…

EDIT:
If the problem is the fedora path we could edit the file path in the hook script, so that it can change depending on the distro…

I think here we need to step and ask, what would need to happen to make jabref work with the firefox snap instead, can it work at all? We would probably need some kind of interface (then we can think how that interface can work wrt the unconfined firefox).

@jdstrand The fix to have the script always run confined is now merged.
@pedronis It’s not a jabref issue, this depends on:

  • does the firefox snap have access to a folder (like /usr/lib/mozilla) where these files can be shared?
  • Is there an issue of a snap calling another snap (I’m not sure about the internals of the native-messaging-hosts)?

My personal opinion is that an interface might be needed here to allow communication between certain types of snaps/files. But for now I’m not sure there’s a better way.

I imagined that the firefox snap would be a content provider, then jabref would plugs this content and drop files into the location (or otherwise register it) such that firefox could pick them up. This could conceiveably work for extensions as well. With this, jabref (or extensions) obviously run under the firefox confinement and this has the potential to break firefox, so we would want to maintain the default for auto-connection of the content interface and not allow other publishers to auto-connect. A process could be put in place for allowing auto-connection of certain snaps, but mozilla would likely need to be involved.

Once the content snap is available this could be a viable implementation.
But still, a way to integrate non snap browsers is needed.
And at this time the non snap version of firefox is the main implementation.
Is the current snap with system files connection something that can be agreed on?
The connection to a snap version of firefox is a welcome addition, but is something
that has to be made available, and does not remove the need for this connection.

Any updates on this?

@reviewers
Any updates?
If this request can be granted another could be asked for the chrome/chromium browsers.
(Non snap, snap versions after a content snap is available)

@jdstrand @pedronis
Is there anything I can do to make this go forward?
If not there needs to be a different strategy, because with this request pending the snap is not updating on the store