@advocacy - can you please perform the vetting?
Thanks @jdstrand, and sorry if I insisted 
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?
@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:
I cannot find the error… am I missing something?