QProcess and Sailjail

Applications C++
#1

Is there a Sailjail permission that I need to use in order to be able to execute a binary / executable file in my application using QProcess? And which locations / folders are allowed to be used to place that binary in?

The binary to be executed via QProcess is currently stored in ~/.cache/org.name/AppName/folder/ and everything works fine as long as sandboxing is disabled, but I can’t figure out what to do to make it work with sandboxing enabled.

Another question. Can someone please point me to some instructions/documentation, or simply tell me what I need to do to make my application listed in the “Share” dialog, so that e.g. pressing and holding a link in web browser and selecting “Share” shows my application on the list, so that the link can be sent to my application.

I already included “MimeType=” with the right mime types list in the .desktop file as well as the “Sharing” permission, but I can’t figure out what else is needed.

Thank you.

3 Likes
Interest to create a cooperative
#2

I think you are asking something Sailjail is specifically meant to block… But depending on your needs, you could pre-package the application and bundle it in Chum, for example. Multi-binary applications are on the whishlist still.

If Harbour compatibility is not the goal here, I suppose you could have a look at firejail profiles and whitelisting files/folders, that way you could still use Sailjail instead of opting-out. Whisperfish uses this approach to allow using shared location for emojis, for example.

About sharing plugin, have a look at the source code, it has good examples, too.

3 Likes
#3

OK, as you suggested, I will have a look at firejail folder whitelisting and the sharing plugin sources. Thank you!

#4

Not quite. Jolla explicitly has a ‘Compatibility’ permission (unknown lifespan) that allows, among others, me to use /usr/bin/ffmpeg . It is limited:

It is possible, I believe, to push binaries into /usr/share/appname/lib and call them even in a sailjail context, but I haven’t tried this for a while. I think @karry has recently done some harbour compatible packaging in that direction?

2 Likes
#5

Have you tried pushing the app into /usr/share/AppName/lib ? Not sure if it works with sailjail.

1 Like
#6

Multiple binaries distributed by the application is still not allowed regardless.
Compatibility permission is for a few select “system” tools.
And apparently not sneak-shipping binaries in config directories is enforced… interesting!

1 Like
#7

I wasn’t sure about that because of some private communication that implied otherwise. It’s certainly what I’d expect. But I didn’t expect D-Bus to become useless :wink:

#8

Actually, the application isn’t going to be distributed. It is being made on request, for someone’s own use. But it would be appreciated if the app was sandboxed, if possible. So, while I have it working OK with sandboxing disabled, I’m at least trying if I could make it work with sailjail…

No, I haven’t tried it. I will check it right away.

And what if the second binary isn’t distributed by/with the application but downloaded by the application after it gets installed? Would it make any difference?

Neither did I :confused:

#9

It is true, when you add some elf binary to /usr/share/harbour-<app-name>, rpm validator refuse it. But still, you can execute binaries from /usr/bin… So you may add ffmpeg.zip to your share folder, unzip in runtime to ~/.cache and execute it there. Unless home directory is mounted with noexec flag. But it is not there :wink:

#10

I’ve created a sharing plugin based on the Nemo Transfer Engine as suggested. Everything works perfectly fine, except for one thing: each time a new instance of an app is launched instead of sharing with an already opened instance. So if I want to e.g. share an URL from the web browser to my application then it is launched and gets the link. But if I then share another link, a separate new instance of my application is launched rather than the already working instance getting the new URL.

Adding

X-Nemo-Single-Instance=no

to the desktop file doesn’t have any effect.

Is there any way to enforce the plugin to share content to the already working application instance?

#11

Whisperfish does this using DBus in QML-only fashion, have a look at the sharing QML and the main QML files for details.

I don’t know DBus enough to comment about Sailjail compatibility OOTB, just so you know :slight_smile:

2 Likes
#12

Thank you! I will investigate it.

As for Sailjail, I’ve already given up on it in this case anyway :stuck_out_tongue_winking_eye:

#13

Well, if you are launching the executable, that has nothing* to do with the .desktop file, or assisted single-instance launching.
I think what the built-in apps do is detect that they are already launched and dbus-call the old instance from the new, which then exits.

if we could figure out how to “launch” .desktop files, that would be neat, but for whatever reason everyone seems to have decided that xdg-open:ing them was only ever a bug and not intended functionality. And nobody provides a generic replacement for whatever purist reason.
Although this wouldn’t help you getting any data (arguments) passed to the old instance anyway, which you’d need since they are not replaced with the new afaik.

And if you are not going to Store immediately anyway, you are better off just registering the app as a handler for links (to a specific domain, hooking all http is evil!) and not even having a sharing plugin.

*Not counting use as a SailJail config holder, and that is read by SailJail itself anyway and not the executable.

#14

I keep using sharing plugin based on transfer-engine in two apps. It works relatively OK, except for one thing: each sharing action shows up in Transfers as Waiting (or Pending) and then (even though the actual action succeeds) after some timeout it changes on the Transfers list to Failed.

I’ve checked other people’s applications using transfer-engine and it looks the same.

Should I notify the plugin somehow from the destination app that the sharing action was successfully completed? It isn’t nice to have dozens of hundreds of Failed items to clear on the transfer list every couple of days :frowning:

#15

Just looking a the whisperfish code, on completion it does a :

       function done() {
           console.log("DBus shareClient.done() call received");
           shareAction.done()
       }

Maybe that’ll help?

2 Likes
#16

Hi. I was able to include own ffmpeg build to “TimeLapse tools” and pass Harbour rules.

  1. first, ffmpeg is build by ExternalProject_Add CMake command in the project
  2. then pack to ffmpeg.tar by bsdtar (it is necessary to use posix tar format)
  3. install it to /usr/share/harbour-timelapse-tools/bin/ffmpeg.tar (Harbour do not allow multiple binaries, but you can have them in tar :wink: )
  4. during runtime, extract tar by simple compiled-in tar library to ~/.cache/cz.karry.timelapse/TimeLapseTools/ffmpeg
  5. execute ffmpeg by QProcess from cache dir
3 Likes
#17

That is SO EVIL :slight_smile:

I went the route of ‘asking’ users to install the system version, which is a pita, but means I don’t have to maintain the ffmpeg build. It turns out that the SFOS version is 4.4.x which was newer that what I had installed on my desktop, so I was fine with that.

I noticed you’re building 5. Any concrete advantages over 4.4?

2 Likes
#18

I’m not aware of any big advantage of this new major release. I just pickup newest released versions of dependencies.

#19

Unfortunately, it doesn’t seem to make any difference. It just closes the sharing requester.

#20

Without looking at code, I’d just be poking in the dark at this point. If you can share the code, let us know!