[messagingframework] Register a dummy notification service for sailjail. JB#63998

[pvuorela]

Depends on: sailfishos/sailjail-permissions#152

Would be nice if this wasn't needed at all, thus not yet pushing upstream, but seems like xdg-dbus-proxy would need changes to work properly with these signals without registration. Sigh.

cc @dcaliste

[dcaliste]

I agree that firejail rules for xdg-dbus-proxy should allow *. At least it seems so.

Anyway, it's strange it didn't create issues during tests… Maybe it's because we have only one client running at a time (the mail app).

About the patch, I'm ok to have it here. Maybe with a unregisterService() call in the destructor also. But I don't think it makes sense to have it upstream : each client is peculiar and doesn't provide a session-wide central service like the messageserver can do. It's just a band-aid as you said for xdg-dbus-proxy.

[dcaliste]

Reading a bit more the documentation (https://man.archlinux.org/man/firejail.1 in particular the --dbus-user.broadcast=name=[member][@path] entry, it seems to me that it's because the connection to the session bus from the client is using a random name. Maybe a proper (upstreamable) solution would be in qmailstorenotifier_p.cpp, to connect to the session bus with QDBusConnection::connectToBus(QDBusConnection::SessionBus, "org.qt.mailstore.client" + rand()). Like that the filtering of firejail will work as expected with .* filtering. I believe it's like what you're proposing by registering a service, but without the service aspect ;-)

But it requires to store the obtained connection and use it everywhere. Not sure it will be simple or even doable…

[pvuorela]

Updated with the unregister service just for completeness even though generally it shouldn't do much.

Reading a bit more the documentation (https://man.archlinux.org/man/firejail.1 in particular the --dbus-user.broadcast=name=[member][@path] entry, it seems to me that it's because the connection to the session bus from the client is using a random name. Maybe a proper (upstreamable) solution would be in qmailstorenotifier_p.cpp, to connect to the session bus with QDBusConnection::connectToBus(QDBusConnection::SessionBus, "org.qt.mailstore.client" + rand()). Like that the filtering of firejail will work as expected with .* filtering. I believe it's like what you're proposing by registering a service, but without the service aspect ;-)

Not per se "random name" but just that the current firejail / xdg-dbus-proxy configuration doesn't allow to make a rule that allows a specific signal (specific interface and maybe even path) from anyone. It supports on ".*" so that the service must have common prefix. Now since here there hasn't been such a name even registered, it hasn't been possible to track this.

That's just stupid and IMO the simplest fix would be to make xdg-dbus-proxy allow also "*" without the dot part. The first surprising part to me is that this hasn't been implemented.

Why this thas worked as it has: when entering a folder etc there are refreshes done and data loaded and that doesn' need any external suggestion to do so. Think that has made it work for most part. Myself I was testing a case where I opened EAS account inbox, sent myself an email from elsewhere, triggered a sync and followed how nothing happened though in the background there was a bling sound.

In the meanwhile while xdg-dbus-proxy is what it is, this wouldn't be really that bad for upstream. It's just that it's maybe only needed for this sandboxing case.

[dcaliste]

Yet another suggestion could be to write the rule as :

dbus-user.broadcast :1.*=org.qt.mailstore.*@/*

I would respect the .* spirit of xdg-dbus-proxy rules. Not sure if it works in practice though, and how we could rely on the first x in :x.xxx being always a 1.

The current patch is doing the job though (and has been tested) so it looks good to me.

[pvuorela]

Yet another suggestion could be to write the rule as :

Heh, that's cleverly thought :D Might even work but if I'd have to guess (without actually trying) I'd assume no, though. Generally the filtering makes more sense with registered names rather than connection names so I'd assume xdg-dbus-proxy wouldn't try those. And anyhow surprising as rule so thinking this current is lesser bad.