Now that sharing plugins are run out-of-process from where it was invoked from, they no longer inherit permissions from that app, which is good. However, currently they seem to have full user permissions, which isn’t so good.
Since SailJail permissions are .desktop-file based and sharing plugins doesn’t have any, how will that work?
This remains a good question. Any clues?
Yes, definitely, enlightenments (–human-readable) would be great about how/how much android apps interact with the system.
Thanks
This thread is about native sharing plugins, not Android apps.
Oh, ok, I confused. But even, important question, still.
Maybe @vige can contribute to this, because it would be really helpful to learn something specific about how to let an app perform “sharing” (on the sending and receiving end) in conjunction with SailJail, now that SailfishOS 4.4.0 EA is released.
Generally the sharing system will show a dialog to choose an application to use for sharing. The selected application will run with its own privileges. On some cases the sharing will be done inside the dialog, but that is restricted for the system side, e.g. bluetooth which wouldn’t have any application either.
If app can be used for sharing, it should declare related properties in the .desktop file.
Is declaring sharing capability in the desktop file allowed (in store) yet?
Nope: https://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/harbour-qa/allowed_permissions.conf
I don’t think it is a SailJail permission… Just regular mimetype stuff.
Or you meant outgoing? I’m concerned with incoming “open-with” functionality.
I was under the impression that’s all related. But then, I was just now also thinking about Contacts (Fernschreiber not being able to access…) and Sailjail.
Open-with does however break the sandbox, doesn’t it? EDIT: https://github.com/sailfishos/sailjail-permissions#readme
lists Sharing as one to not use directly. I’m just confusing matters.
It won’t be a permission but the final bits for the sharing method registration didn’t make it on this release yet.
@attah can you point us at an example ? Do you mean as in App as endpoint in Share API chain - #3 by nephros
With sharing plugins being run out-of-process, i mean that the dialog that is provided by the plugin is run in a separate process from the app that invoked it. Example sharing plugin: https://github.com/attah/harbour-seaprint-share-plugin.
So i was wondering what limitations SailJail will put on what those can do, when they themselves have no place to declare permissions. This is mostly in the light of that i invoke SeaPrint from my plugin.
The answers i interpret as that sharing plugins will only ever have base permissions. And the need for doing fancy things in plugins (and making plugins) should be greatly reduced by the upcoming open-with functionality (already available for Android apps). This is what you linked to, but it may get a bit repackaged since it isn’t released/allowed yet.
My sharing plugin was only really ever a workaround, so i’m happy sharing to SeaPrint will become much cleaner and easier. If just in a version or two…
Ah, I hadn’t thought of the dialog. Thanks for clearing that up. Now how do I test your plugin? Does it need to be built/installed separately from seaprint? I was testing with v1.0.4.
Sadly, on 4.4 you don’t. The sharing infrastructure has changed again, and even if i was to adapt to it, the plugin would be too jailed to do what it currently does. But otherwise, you just install it alongside SeaPrint (it is packaged in OpenRepos).
Compared to SFOS 4.2.0, where Jolla vastly altered it the last time? Really again?
Do you have a pointer at hand to the documentation of the “new again in 4.4.0” sharing-infrastructure?
Thank you for the link to the comprehensive discussion.
So once again a new sharing API!
On the upside, most use-cases won’t need it soon.