Sailjail and D-Bus interaction between apps

Applications
#1

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:

How does ExecDBus actually work?
Sailjail vs. DBus (SystemBus) calls
Community meeting on IRC 11th January 2024
Community meeting on IRC 21st December 2023
Sailjail issues with Pure Maps
#2

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
#3

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.

#4

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
#5

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…

1 Like
#6

Thank you this one helps me with another problem!

#7

I am hitting DBus communication the issue with Pure Maps. Pure Maps allows you to relate your position to a street, align it with the street, and get the current speed limit. Under the hood, it is using OSM Scout Server for it and its map matching service. To make such requests fast, DBus communication between Pure Maps and OSM Scout Server is used.

Now, with this new and shiny Sailjail implementation, I don’t see how we can whitelist DBus services in the apps. I can surely just disable Sailjail in Pure Maps for the version distributed in Chum and that will be done anyway for TTS.

However, I think we should be able to allow permissions for default Linux communication channel between applications in SFOS, as it is Linux after all. As an example, here is how such permission is handled in Flatpak where app developer can specify “talk-name”. Something similar is needed for Harbour approved apps as well.

#8

Yeah, this is stunning. Not permitting D-Bus effectively dumps the only standardized method there is. I frankly don’t get it. And before someone says security, no.

3 Likes