Sailjail and D-Bus interaction between apps

Hi there,

at the moment I am struggling to get D-Bus interaction between two sailjailed apps working.

I try to call a D-Bus method of app A inside app B.

App B accessing Interface in app A:

DBusInterface {
    id: dbusInterface

    service: "org.nubecula.sailhub"
    iface: "org.nubecula.sailhub"
    path: "/"
}
...
dbusInterface.call("addStar", ["black-sheep-dev", "harbour-hafenschau"])

Heres the desktop file of app B:

[Desktop Entry]
Type=Application
Icon=harbour-hafenschau
Exec=sailjail -p harbour-hafenschau.desktop /usr/bin/harbour-hafenschau
Name=Hafenschau
Categories=Network

[X-Sailjail]
OrganizationName=org.nubecula
ApplicationName=hafenschau
Permissions=Documents;Internet;Sharing;WebView;Audio
ExecDBus=/usr/bin/harbour-hafenschau -prestart

Heres the desktop file of app A:

[Desktop Entry]
Type=Application
Icon=harbour-sailhub
Exec=sailjail -p harbour-sailhub.desktop /usr/bin/harbour-sailhub
Name=SailHub

[X-Sailjail]
OrganizationName=org.nubecula
ApplicationName=sailhub
Permissions=Internet
ExecDBus=/usr/bin/harbour-sailhub -prestart

When I call the method of app A from a non jailed app or over console with dbus-send everything works as expected. So it belongs to the permissions of app B?!?

Inside the sailjail permissions readme I found this:

Blockquote
They grant access to certain data paths, D-Bus interfaces, socket types and application binaries. Currently applications must define all needed permissions in desktop file and all of them are granted at launch.

What I need to add to desktop file of app B to get access to the D-Bus Interface of app A?
Or do I need to add something special to desktop file of app A?
Is it supported at all granting access to an other apps D-Bus interface?
Is it maybe forbidden in the future?
Do I need to ship a sailjail permission file or something like that?

This drives me crazy!

Hope somebody can help?!? :disappointed_relieved:

When you look to files in /etc/sailjail/permissions/ directory, for example /etc/sailjail/permissions/Location.permission, you can see that permission definition contains specific D-Bus services that are whitelisted… like:

dbus-user.talk org.freedesktop.Geoclue.*
dbus-user.broadcast org.freedesktop.Geoclue.*=org.freedesktop.Geoclue.*@/*

So, I would guess that that you would need to create specific permission for communicating to application A and request such permission in application B… But it will not be allowed in Harbour I guess.

2 Likes

Hi karry,

thanks for your answer! That’s what I feared.

But why is it possible to define a D-Bus Service, but no jailed app is able access it?

From the readme:

The ExecDBus value is an optional command line which will be used to auto start the application to provide the . DBus service.

This makes no sense for me, especially when all apps are jailed automatically in later releases.

Well, it would be great to bring this question to next community meeting. I doesn’t see practical reason for ExecDBus usage. With current Harbour and Sailjail rules, applications cannot communicate each other via D-Bus, cannot be registered as url handlers (it requires to register D-Bus service)…

The only practical usage for D-Bus service in applications is notification callback AFAIK.

1 Like

Btw @BlacksheepGER, what is your usecase? I recently implemented handling for “geo:” links, see https://github.com/Karry/osmscout-sailfish/commit/c49d12641f9d9f654132f436eec1c218e693da9c When opening such link, system is asking what application to use to open it… It works for jailed application, but it is not allowed in Harbour either, it is necessary to distribute additional files via OpenRepos package :frowning:

I wonder if your usecase may be implemented by custom url scheme…

Thank you this one helps me with another problem!