HI KDE Folks,
I am re-factoring qgenericunixthemes.cpp, where QKdeTheme resides.
It contains some #ifdef’ry to cover the case that QKdeTheme is used w/o DBus, see here.
The question is: can that actually be the case? Should it be covered?
You’re also welcome to review the refactoring patch and / or a patch to add a programmatic color scheme change to QKdeTheme.
Cheers
Axel
I think it is very unlikely that there is KDE Plasma session without D-Bus.
It is simply needed for too many things.
I guess the whole plugin could be made dependent of whether Qt is configured with or without D-Bus.
My only concern would be applications that bundle Qt and which could have been built without D-Bus (for whatever reason).
These would then lose even the integration bits that the current plugin can provide without the D-Bus sections.
hey roughly a year later is development going in a direction to leave d-bus behind (slowly) and replace with more modern and less complex approaches, like IPC and such?
D-Bus is an IPC (inter process communication) technology.
Which other one did you have in mind?
actually my bad i’ve done some research about how KDE uses d-bus and it seems it uses alot of sandboxing and abstractioning of d-bus so it is not directly referenced anymore as it was year ago, so forget what I wrote^^
Hi, I have been trying to understand the D-Bus implementation.
If you still have your history, could you please put some links to where you found useful info?
Thanks
Most KDE software will be using Qt’s D-Bus module.
You can browse the implementation/code on CodeBrowsers.dev or get the code from the public repository.
Programs that aren’t using Qt are likely to use an implementation specific to that technology stack, e.g. zbus for Rust.
Thanks, hehe.
I was just trying to be lazy and see if there is any simplified information regarding the working of it that would answer:
dbus-broker and how the rules are appliedThese things were not answered in the documentation and I would have to properly read the source code to understand them.
The bus implementor, e.g. dbus-broker, listens on a Unix domain socket.
Clients, e.g. a KDE program using QtDBus, connects to that socket.
If/what rules are applied will depend on the bus implementor/provider.
The original (and most common) provider, dbus-daemon, reads rule files from /etc/dbus-1.
D-Bus clients can, of course, also decide how to handle incoming messages.
Not sure what you mean by that.
A sandboxed application can access the bus if it somehow gets access to the socket.
There are helper tools like xdg-dbus-proxy which appear to be the bus from the point of view of the sandboxed app so that the actual socket does not have to be exposed.
Such a proxy may also offer options for filtering rules.
Filtering depends on the capabilities of the bus provider and/or any proxy between the app and the bus
I see, so I should be looking into dbus-broker and dbus-daemon itself to understand the security implications.
And considering that installing KDE programs using cmake also adds dbus configurations, I can assume that the format for those are part of the dbus specification, which is probably extendable to enable using capabilities of specific providers.
Yes, the clients (apps, services) are just send/receive messages to/from the bus (provider).
For dbus-daemon have a look at its documentation, sections “Configuration File”, “SELinux”, “AppArmor”
If you mean .servicefiles for D-Bus activation, then yes.
Considering that systemd is working on Varlink, I would be interested to see what KDE Plasma would look like with Varlink instead of D-Bus. I have no doubt that D-Bus is going to stay for a while, but I feel like there’s a point where it will have to go, even if it’s in any year past 2100.
There’s also a blogpost from a while ago regarding QtVarlink. I should look and see if there’s been any progress on it. I might even see if I have anything to add. :^)
I doubt there would be any visual or behavioral difference as this is mostly a technical detail.
Of course it would require all the other programs Plasma interacts with via D-Bus to also have VarLink capability or for Plasma to support both communication variants at the same time.
I have doubts there will be much of a visual difference. However, the benefits seems much clearer in terms of speed, security, and more modernisms that the old and slowly becoming mold D-Bus.
Makes sense. Most of the ecosystem supports D-Bus and it’ll stay like that for a while. Dropping it as soon as VarLink support is stable would be comedically tragic. I’d probably focus on having compatibility for both until D-Bus is no longer required by anything, but that’ll take a while to be realised.
This is not as clear cut as it may sound.
D-Bus is faster in terms of message construction and parsing since it is a binary format while VarLink uses JSON.
VarLink is faster in terms of message routing because it doesn’t need a daemon to do that.
There were attempts to implement D-Bus providers in the kernel instead of a daemon but these patches did not get accepted.
I doubt there are any differences in terms of security.
Since this is becoming a D-Bus implementation related discussion anyway, I might as well ask.
When using a daemon, you have something that can check which program is sending the D-Bus message. How do you do that in case there is none?
Won’t this become a problem similar to the Notification system, where any program can cite the desktop file of another one?
That will mostly depend on the communication channel.
A lot of local communication on Unix-like system happens on so-called Unix Domain Sockets for the reason that they can pass system data alongside the byte stream, e.g. file descriptors but also process credentials (SO_PEERCRED or SCM_CREDENTIALS).
If the daemon-less setup uses such sockets then it can use the same mechanisms.
One side will even be the socket server, the one that listens/waits for the other process to connect.
Depends on your threat scenario.
In the end you can always fall back to the same techniques used for remote connections, e.g. cryptographical tokens.
I don’t see cryptography as a viable solution in case of same user processes, since any cryptographical ID a process running as user1 can read, can also be read by another process running as user1.
I consider this case as good enough for secure communication on the same system:
root user, it gets all corresponding protections.udisks says, it will only take /usr/bin/dolphin, then the D-Bus would block /home/ulterno/codes/dolphin/build/bin/dolphin unless /usr/bin/dolphin is a link to /home/ulterno/codes/dolphin/build/bin/dolphinAssuming they have read access to each other’s binary and aren’t sandboxed.
And know where inside the other binary the key is stored and how it might have been processed/obfusicated.
As I said this depends a lot on your thread scenario.
You have more option when having a trusted third party as part of the communication, e.g. in the case of Unix sockets the kernel.
Yes, I am essentially talking non-sandboxed applications, because if I am sandboxing them, I can also just place all the executables that I want talking on the same bus, in the same sandbox.
And I don’t see obfuscation to be particularly useful in this specific consideration and am really just looking for the system to say “no” to the application, in a way that it is protected to installation level access (a.k.a. root access).