vaxry talked about LD_PRELOAD and I feel like that is a non-issue in this case.
If an attacker has the ability to modify LD_PRELOAD of an application, they already an ability to modify its behaviour without depending upon what D-Bus may let it do.
And if the attacker can change LD_PRELOAD for a process running as root, they might as well affect the target service directly rather than try doing something with the dbus daemon.
this post was submitted on 15 Dec 2025
31 points (86.0% liked)
Linux
10605 readers
453 users here now
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
founded 2 years ago
MODERATORS
Honestly 80% of the article is ranting about developer not writing proper documentation or following specs which is not the fault of D-Bus. The only point that I agree with is the lack of security features, but that has never really been a thing back then. Half of the shit that was developed was completely insecure. Not saying that's a good thing btw. But that can be fixed.
To be fair, D-Bus is a protocol. Proper documentation and standards is half of implementation. Without any well-defined standards, a protocol is essentially useless and/or lawless. While not every case of non-compliance is the fault of D-Bus, the general lax nature of how endpoints are intended to be defined as well as the incompleteness for the actual standards applications should adhere to is a significant factor for why many applications are the way they are. In addition to the severe security flaws in D-Bus, this could be written with extensions to the protocol, becoming a new standard. Though if the problems are as deeply rooted as they are, it's not entirely out of the question to create another standard that isn't D-Bus.
severe security flaws in D-Bus
I searched for this and all I got was CVEs in the implementations.
What are the flaws in the protocol that I don't know of? If you can link it, I would love to read.
I recently started interacting with code that had something to do with D-Bus and from what I saw, there were policy files, which are required to do anything with D-Bus endpoints provided by software. That's essentially where I stopped, considering that to be the end-all for D-Bus security.
What am I missing?
So, first of all, I barely ever had to work with d-bus directly - I used it a few times and it was fine to use.
Without any well-defined standards, a protocol is essentially useless and/or lawless
When I look for "D-Bus Specification", I get this: https://dbus.freedesktop.org/doc/dbus-specification.html. This LOOKS like a proper documentation of the standard to me.
the general lax nature of how endpoints are intended to be defined ... is a significant factor for why many applications are the way they are
I feel like this is the same complaint people have about other things, like PHP for example. They see shitty PHP code (like wordpress) and are like: "Oh my god PHP is such a shitty language because this application is written like shit". But I don't blame a language, a framework or a protocol for the failures of the users. I don't feel like an application that close to the system core has to be absolutely "dummy proof". At some point, we should just expect that people know what they're doing, and if they don't, we should blame them, not the underlying technology.
I agree with some comments at HN about that proposing an alternative is kinda pointless. D-Bus, contrary to the X situation, can be fixed.
rewrite it in rust
should sort it out :D
Might as well rewrite Shakespeare in Rust, while we are at it :P
Reinventing the wheel won't help
The wheel is fundamentally broken. D-Bus is unfixable due to its core principles being terrible.
With each passing day Vaxry seems closer and closer to re-implementing the entire userland, I don't know how he avoids burning out...
This is quite interesting. I'd been looking into dbus lately and was confused by a few design choices so it makes sense to me that the design is faulty.
Running both simultaneously seems pretty feasible since the session bus bus should be quite lightweight (worse case would be a lot of inter-bus traffic if/when that gets implemented).
Security and kv are excellent features.
I feel it might have more luck gaining adoption if its name did t tie it to hyprland.
Back in 2014 at work we were using and extending dbus-proxy https://github.com/Pelagicore/dbus-proxy because of this weird problem of access rights with D-Bus.
Portals could have been much simpler like how xdg-open works.
I'm surprised it seems nobody has tried to write an alternative to portals that doesn't use dbus?
Sounds good, good luck to the dev!