Sailjail vs. DBus (SystemBus) calls

Applications
#1

Does sandboxing somehow block systemBus DBus calls? Does it take some specific permission to allow them?

The following DBus call:

QDBusMessage mm = QDBusMessage::createMethodCall("com.jolla.apkd",
                                                "/com/jolla/apkd",
                                                "com.jolla.apkd",
                                                "controlService");
mm << false;
QDBusConnection::systemBus().call(mm);

works perfectly fine only if I disable sandboxing. As soon as I enable sandboxing, it just stops working.

I also tried doing it as a QML-only app, e.g.

DBusInterface {
    id: apkInterface
    bus: DBus.SystemBus
    service: 'com.jolla.apkd'
    path: '/com/jolla/apkd'
    iface: 'com.jolla.apkd'
 }

apkInterface.typedCall("controlService", [{ "type": "b", "value": false }])

with the exact same result, i.e. it works OK only as long as sandboxing is disabled.

Does anyone know what to do (e.g. which permissions to use, or whatever else needs to be done) to make it work with sandboxing enabled?

It seems to be affecting SystemBus calls only. In my other apps I use some SessionBus calls, which work OK regardless of whether sandboxing is disabled or enabled…

#2

Related:https://forum.sailfishos.org/t/sailjail-and-d-bus-interaction-between-apps/9874

#3

I’ve seen it. But that topic is about communication via DBus between two different applications, whereas in my case it is about calling a service/method of the OS. And it’s about SystemBus calls only, because in my other apps I successfully use SessionBus calls with sailjail enabled. So I am not sure if there’s a relation to that topic.

1 Like
#4

Are the other apps where it works available to look at?

#5

Not yet. The plan is to make some of them available at some point, after I find the time to polish them for release. I’m still in the process of porting my apps from BB10 to Sailfish and I often get bored with porting one application and switch to porting another, which causes that all of them are in quite an unfinished state :slight_smile:

Anyway, an example of such a DBus call that works OK with sandboxing enabled is e.g.

QDBusMessage m = QDBusMessage::createMethodCall("org.nemomobile.voicecall",
                                            "/calls/active",
                                            "org.nemomobile.voicecall.VoiceCall",
                                            "hangup"); 
QDBusConnection::sessionBus().call(m);

that I use in an application to filter/block unwanted calls.

And also e.g.

QDBusInterface voiceCallIf("org.nemomobile.voicecall",
                       "/calls/active",
                       "org.nemomobile.voicecall.VoiceCall",
                       QDBusConnection::sessionBus());
is_Incoming = voiceCallIf.property("isIncoming").toBool();

that I use to monitor only incoming calls.

And actually any other DBus call via SessionBus. On the contrary, all SystemBus calls that I’ve tried only work if sandboxing is disabled…

#6

I think the short answer is that it depends on the DBus interface you’re trying to access, and the permissions that the app is requesting.

For example, the Blueotth permission exposes org.bluez on the system bus (line 15), and com.jolla.Bluetooth on the session bus (line 19).

If there’s some particular access you want, right now the best way to check is probably by searching through the permissions files in the sailjail-permissions repository.

#7

OK, so can you please advise which permission am I supposed to use in this very case, i.e. com.jolla.apkd.controlService? Because none of what I’ve tried had any effect. Nor can I find any permission matching this functionality.

#8

I’m afraid I don’t know specifically about com.jolla.apkd.controlService but I don’t see it in any of the permissions files.

The most likely reason is that it’s not one that’s currently available. Some DBus interfaces are consciously restricted (e.g. the PackageKit’s DBus API has always been restricted), while others may simply be oversights (there are a lot of them to consider).

If you think it’s a case of the latter, then probably the best thing to do is to create a post about it in either the Bug Reports or Feature Request categories. That’ll allow for a proper discussion, for example about whether it makes sense to allow it, what permission it should fall under, etc…

I hope that helps.

1 Like
#9

I don’t think starting and stopping apkd is something that’s going to be included in a public permission. You’d have to bundle your own permission file to do that, or disable sandboxing in your application desktop file. Neither of those would be generally be permitted in the harbour store, but I guess if you’re doing that sort of thing then you’re not aiming for that anyway :slight_smile:

1 Like
#10

@abranson Please note that the official Sailfish OS documentation of the D-Bus APIs (that @flypig linked above) states that access to com.jolla.apkd System bus service is “Unrestricted, with exceptions for special package installations”.

So, one would expect some more consistency here. “Unrestricted access” stated in that documentation definitely doesn’t sound like something that not even just requires some special permission, but that actually “isn’t going to be included in any public permission” at all…

As for Harbour, I believe that it has its own, separate set of restrictions which should not affect what’s NOT meant to be distributed there.

1 Like
#11

I’m afraid that’s much more likely to be due to the documentation needing updating than due to some policy conflict. It looks like that page hasn’t been updated for quite some time, and definitely not much since sandboxing was introduced, and it needs an overhaul perhaps with a new column to state which harbour-allowed permissions are needed to access each service. Technically it’s still true that un-sandboxed applications can access all of those APIs though, and from your last sentence it sounds like that’s what you’re planning to do anyway?

For reference, the harbour restrictions on permissions are here hhttps://github.com/sailfishos/sdk-harbour-rpmvalidator/blob/master/allowed_permissions.conf. Applications cannot currently be accepted into the Jolla store using any not on that list.

1 Like
#12

OK, but I still don’t understand why you’re referring to sandboxing in the context of Harbour/Jolla store app distribution only, and for anything else you’re suggesting to just disable sandboxing and be fine. There are many other, not any less serious than harbour, application development goals and purposes, where sandboxing is still desired.

#13

You’re absolutely right, and you’ll notice there are more permission types available than are allowed in Harbour in recognition of this. But in general our focus is Harbour compatibility because we don’t restrict or control what other stores do.

It’s also worth bearing in mind that in practice when @abranson or one of the other Sailjail developers looks at a potential permission, there are many different factors to consider. Permissions have to be easily understood by users. They shouldn’t be too granular or too broad. Some permissions that might look benign at face value — such as installing native third party apps — in practice degenerate into root access, and so simply can’t be tightly defined by a permission without changes to the underlying implementation.

#14

Thank you for your answer. Please let me add just two remarks.

  • While maybe com.jolla.apkd service functionality may seem not very important from an average developer and user perspective, at least its function to start/stop the Android support is quite important and very often requested. There is quite a number of posts on the Feature requests forum asking for one or another form of this functionality (e.g. the aforementioned configurable timer). I also remember reading a post somewhere in which a small company whose employees had Sailfish OS phones were looking for developers to make an application for them to automatically disable Android support when the user comes to work (his phone logs in to company’s WLAN network and/or GPS coords match the company’s location).- for security reasons. Because Android support is not only a resource hog, but it is also often considered a security threat in certain situations/environments. So being able to at least start and stop it programmatically (without having to sacrifice other security measures for this, like having to give up on sandboxing) is quite desirable.

  • Yes, I understand that I can disable sandboxing for this very functionality. But please note that it enforces disabling sandboxing for the entire application, i.e. also for all its other functions, possibly much more security-sensitive.

Anyway, as you suggested in your previous post, I will consiider posting it as a Feature request.

1 Like
#15

Thanks for explaining; it’s certainly helpful to be clear on the things you’re thinking about.