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

@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)

Is there anything that we can do to accelerate the vetting process?

@Wimpress or @popey - can you or someone you assign from @advocacy please perform the vetting?

@Wimpress, @popey or @Igor - can someone do the vetting?

@jdstrand
This is getting a bit hard to follow up on… Can the vetting start from the jabref team? Since they are involved and the snapcraft yaml is on their github account…
Who can we contact to get the vetting started directly?
Thanks

Apologies for the delay. We need to improve our process for dealing with these requests, which we will endeavor to do.

Vetting done. +1

1 Like

Thanks @popey

Granting use of without auto-connection for system-files when the snap 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
  etc-opt-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:
    - /var/lib/snapd/hostfs/etc/chromium/native-messaging-hosts/org.jabref.jabref.json

@LyzardKing - fyi, looking at the snapcraft.yaml in the store, I see that:
a) it is malformed (‘plugs’ is under ‘plugs’)
b) you are using hostfs to access files in /etc. Just use /etc

Looking at you latest snapcraft.yaml, adjust to use:

name: jabref
...

plugs:
  desktop: null
  desktop-legacy: null
  gnome-3-28-1804:
    interface: content
    target: $SNAP/gnome-platform
    default-provider: gnome-3-28-1804
  gtk-3-themes:
    interface: content
    target: $SNAP/data-dir/themes
    default-provider: gtk-common-themes
  home: null
  icon-themes:
    interface: content
    target: $SNAP/data-dir/icons
    default-provider: gtk-common-themes
  network-bind: null
  opengl: null
  hostfs-mozilla-native-messaging-jabref:
    interface: system-files
    write:
    - /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/org.jabref.jabref.json
  etc-opt-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:
    - /var/lib/snapd/hostfs/etc/chromium/native-messaging-hosts/org.jabref.jabref.json
  removable-media: null
  sound-themes:
    interface: content
    target: $SNAP/data-dir/sounds
    default-provider: gtk-common-themes
  unity7: null
  wayland: null

apps:
  browser-proxy:
    command: lib/jabrefHost.py
    command-chain:
    - snap/command-chain/snapcraft-runner
    - snap/command-chain/desktop-launch
  jabref:
    command: bin/JabRef
    command-chain:
    - snap/command-chain/snapcraft-runner
    - snap/command-chain/desktop-launch

(fill in the ‘…’ for all your other stuff)

Notice that when you use a top-level ‘plugs’ and you don’t use ‘plugs’ under the ‘apps’ commands, all of the toplevel plugs are used for the app. If this isn’t what you want, remove all the ‘null’ items from the top-level plugs and do something like:

name: jabref
...

plugs:
  gnome-3-28-1804:
    interface: content
    target: $SNAP/gnome-platform
    default-provider: gnome-3-28-1804
  gtk-3-themes:
    interface: content
    target: $SNAP/data-dir/themes
    default-provider: gtk-common-themes
  icon-themes:
    interface: content
    target: $SNAP/data-dir/icons
    default-provider: gtk-common-themes
  hostfs-mozilla-native-messaging-jabref:
    interface: system-files
    write:
    - /var/lib/snapd/hostfs/usr/lib/mozilla/native-messaging-hosts/org.jabref.jabref.json
  etc-opt-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:
    - /var/lib/snapd/hostfs/etc/chromium/native-messaging-hosts/org.jabref.jabref.json
  sound-themes:
    interface: content
    target: $SNAP/data-dir/sounds
    default-provider: gtk-common-themes

apps:
  browser-proxy:
    command: lib/jabrefHost.py
    command-chain:
    - snap/command-chain/snapcraft-runner
    - snap/command-chain/desktop-launch
    plugs:
    - desktop
    - desktop-legacy
    - gsettings
    - home
    - network-bind
    - opengl
    - removable-media
    - wayland
    - x11
    - hostfs-mozilla-native-messaging-jabref
    - etc-opt-chrome-native-messaging-jabref
    - hostfs-chromium-native-messaging-jabref
  jabref:
    command: bin/JabRef
    command-chain:
    - snap/command-chain/snapcraft-runner
    - snap/command-chain/desktop-launch
    plugs:
    - desktop
    - desktop-legacy
    - gsettings
    - home
    - network-bind
    - opengl
    - removable-media
    - wayland
    - x11
    - hostfs-mozilla-native-messaging-jabref
    - etc-opt-chrome-native-messaging-jabref
    - hostfs-chromium-native-messaging-jabref

Point is, if you are going to specify plugs down under apps that are different for each command, then specify them all there, referencing the interface references in the top-level plugs. Otherwise, just use the top-level plugs and omit the ones down under apps.

@LyzardKing - finally, while the store now has the snap declaration in place, there is a review-tools change that is needed that I’ve made to master but isn’t in production yet. Feel free to upload new revisions based on my comments above and we can manually approve them until the store has the change in production.

Thanks @popey!
@jdstrand I had used only top-level plugs since the second app (browser-proxy) is a “launcher” for the first one (via the messaging hosts).
I’ll remove the nested plug (likely a typo on my end) and republish.

@jdstrand Should I remove hostfs from this as well?

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

to

etc-chromium-native-messaging-jabref:
    interface: system-files
    write:
    - /etc/chromium/native-messaging-hosts/org.jabref.jabref.json

Oh! yes, please remove that too and use exactly what you suggested. I’ve adjusted the snap declaration and the review-tools accordingly.

@jdstrand The snap builds but fails to release:
https://build.snapcraft.io/user/JabRef/jabref/858770
I cannot find the error… am I missing something?