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
Thanks
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.
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
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
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:
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?
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.
Thanks