Problems with D-Bus on the Linux desktop
218 comments
·December 15, 2025charcircuit
jabl
Yes! Make something built on top of binder, and use something with orders of magnitude more users and developer resources behind it..
> hardened stuff that already exist.
To make it even more hardened(?), Google recently contributed and got merged a Rust implementation of binder for the Linux kernel (and they're apparently planning to eventually remove the old C implementation).
https://lwn.net/Articles/953116/
https://lore.kernel.org/rust-for-linux/20231101-rust-binder-...
bee_rider
Which OS? I didn’t get many results for BSD binder. Then I figured maybe you were joking about the “serious” part, so I tried windows binder, iOS binder, didn’t see much…
charcircuit
Binder is the primary way apps talk to the various OS services on Android.
https://source.android.com/docs/core/architecture/ipc/binder...
https://www.kernel.org/doc/html/latest/admin-guide/binderfs....
AshamedCaptain
There are few implementations of the Binder userspace outside of Android.
pseudalopex
How many implementations existed of their new bus?
AshamedCaptain
Considering that any new implementation of Binder userspace would realistically also be incompatible with Android Binder, what would really be the gain here? You'd basically have yet another wire protocol that nobody else uses but now also depends on having a obscure Linux feature enabled.
aryonoco
Not widely known but the original Binder, OpenBinder, was not even for Linux or Android It was developed for BeOS.
OpenBinder was one of the few pieces of code which was open sourced in Be Inc’s dying days just before it was acquired by Palm.
Many of the principal Be developers who worked on OpenBinder, Dianne Hackborn, Jean-Baptiste Queru, et al then moved from Palm to Danger, which was developing Android and which was later acquired by Google.
And the rest, as they say, is history.
zb3
Binder will come to linux desktop soon... together with Android :)
_flux
From the style of this article I expected that https://github.com/hyprwm/hyprwire and https://github.com/hyprwm/hyprtavern would have documentation, specification and perhaps a bunch of tests, but they're not really there (other than smoke tests).
Those would have been a great starting point as well! But maybe we'll see them later.
wpm
I believe the sole author is doing finals for their last year of university at the moment.
pjmlp
D-Bus is the closest Linux desktop has from XPC, COM, Android IPC.
Maybe it should be treated better, not rebooting it every couple of times.
The problem is naturally the Linux desktop fragmentation that hinders a proper full stack approach to application development.
What works for GNOME is useless for KDE, and what works for KDE is useless for XFCE, which is ignored by Sway and so forth.
jabl
> What works for GNOME is useless for KDE, and what works for KDE is useless for XFCE, which is ignored by Sway and so forth.
KDE had their own IPC thingy, DCOP, but it has been replaced with D-Bus.
pjmlp
Yep, using Linux in various forms since 1995.
bjourne
D-Bus is over 20 years old so a reboot is in order. All this guy's gripes are not legitimate, but many are. However, upgrading desktop infrastructure is just as much about influence (clout) and "social" excellence as it is about technical exellence. A new ipc mechanism that is not backed by the major players has no chance.
continue-100
I'd argue vaxry _is_ a major player, what with the rise of omarchy.org and r/unixporn, popularizing hyprland enough for him to have enough momentum to publish standards for this new era of TWM linux desktop.
tguvot
actually kde has kparts which are somewhat like com. prior to d-bus kde used to use dcop.
c-hendricks
God I loved kparts, but wasn't that more the idea that everything should be embeddable?
> KPart technology is used in kde to reuse GUI components ... By using kparts in applications developers can spend less time implementing text editor or command line features, for example and just use a katepart or a konsolepart instead.
Gualdrapo
Yes it is, but since "KDE 5" I've seen less of it. Besides the obvious example of Konqueror another great example of it was reKonq, which used Akregator, Okular and Kget to handle RSS and PDFs respectively (all within the reKonq window).
Now not even Falkon does that.
pjmlp
It does, but again only usable by KDE apps.
GalaxyNova
The fragmentation is a natural consequence of different use cases existing.
You can't have your cake and eat it too.
wryun
OpenWrt devs had this epiphany many years ago:
https://openwrt.org/docs/techref/ubus https://openwrt.org/docs/techref/ubus#what_s_the_difference_...
(no endorsement implied; in particular, ubus has not much of a security model, though OpenWrt has an excuse for that)
bflesch
The problem with dbus is also that all these nice browser extensions that integrate websites with gnome/kde talk over dbus. These dbus APIs had several DOS vulnerabilities, some of which could be triggered by visiting any website. It is unacceptable that my desktop environment crashes just because something floods the dbus API, even moreso if it can be triggered by visiting a website.
So if you are a security researcher, dbus is a very worthwhile entry point if you want to improve some open source software :-)
psanford
What browser extensions? Why would I want websites to integrate with gnome or kde? What does that even mean?
stefanfisk
Isn’t this bad boy installed by default in most Gnome distros? https://chromewebstore.google.com/detail/gnome-shell-integra...
airhangerf15
I'm guessing the poster meant the USB and Bluetooth browser protocols (which I still find insane how anyone thought those were a good idea, but it's literally the only way to configure some keyboards today).
Terr_
> Ever seen kwallet or gnome-keyring? Yeah, these things. These are supposed to be "secret storage" for things like signing keys, passwords, etc. They can be protected by a password, which means they are secure... right? [...] any app on the bus can read all secrets in the store if the store is unlocked.
Well, TIL. Looks like the default GUI for that is `seahorse`, so let's see what I've got on a relatively fresh installation... Looks like mostly Chromium stuff where there's a key that unlocks something more application-specific (e.g. for Discord) and an access token for my JetBrains account.
So no plaintext passwords per se, but now I wonder what a malicious app might uncover if it pursued the local Chromium stuff.
XorNot
Where do you think those secrets are going to be stored otherwise and how are you planning to authenticate to them?
If you're not entering a password at some point, then they're in memory and available to all anyway. If no system prompts or notifies you access is happening, then it's irrelevant what software machinations might be governing this.
jeroenhd
On platforms like Android, iOS, and macOS, secrets are easily stored encrypted with no access to the key unless you exploit the kernel. On Windows, a similar feature is opt-in, but compatibility makes it a little less reliable.
iOS and macOS combine sandboxing with their Secure Element. Android uses TEE or a secure element-like piece of hardware. Windows uses a hypervisor + the (f)TPM.
Nothing Linux can't do, it's basically glueing together a small early boot KVM VM + TPM + secure boot together with an API. Setting up your own secure boot keys to make it run relatively seamless is a pain on many consumer devices, though.
XorNot
All of that is about protecting secrets at rest on the device. It is of no protection at all if an application simply asks the secure-whatever for them and then proceeds to email them all to someone else.
The secrets in the keyring of my secure boot protected, full disk encrypted laptop are exactly as secure until I boot it up and unlock the keyring for Dbus.
pseudalopex
> If you're not entering a password at some point, then they're in memory and available to all anyway.
They entered a password to log in probably. And Linux had a setting to restrict ptrace since years.
Terr_
When Important Banking App stores a secret to my "keyring", I would never have expected that the "secret" would be trivially available to all other programs that run.
Imagine if it worked that way for browsers, and every website with a saved-password got to see all the other saved passwords...
skydhash
Why is your banking app entering a secret to your keyring? That would be like writing your safe code in a paper and let it hang onto a physical keyring.
ghusto
> However, the best thing is this: any app on the bus can read all secrets in the store if the store is unlocked
>> The GNOME project disagrees with this vulnerability report because, according to their stated security model, untrusted applications must not be allowed to communicate with the secret service.
I'd like to point out for anyone on the fence that yes, Gnome is run by clowns in full sized clown shoes.
rcxdude
This is especially amazing given how much of wayland friction is in the name of security ("Why would we ever standardise a way to intercept and send keystrokes? it's not secure!")
skydhash
I always thought as the secret for things that should not be saved non-encrypted on disk, not for things that should be kept hidden from other applications. And if that is your threat model, you should look into virtual machines.
WD-42
That’s exactly what it’s for. Parent is just being rude for no reason.
k4rnaj1k
[dead]
Spivak
Program running as user can read data owned by user. If this is a vulnerability then the entire linux userspace is compromised. Can you believe that applications I run can execute gpg2 and steal all my secrets?
The dbus process is run by and owned by your user. The only people that can access it is you and root. There is a system-wide bus but your secret manager isn't using that one.
It's just this: https://xkcd.com/1200/
wpm
It’s almost as if the user/group/everyone permission model developed for time sharing mainframes isn’t sufficient anymore for absolutely everything anymore.
Asooka
Fortunately today with AI everyone CAN actually audit all the code for all the software running on their machine themselves by sending it to a black box cloud service, thereby running only software they KNOW they can trust! /s
tocariimaa
"works as intended wontfix conversation locked"
publicdebates
I wonder if the design of D-Bus has anything to do with a principle I notice a lot, where the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness. For example, I wonder how many repos on github have legitimately created a 100% better framework than React, but the author simply can't get the word out for whatever reason, so the project remains accidentally anonymous. Maybe D-Bus has something similar?
bawolff
> the most meritorious solution never rises to the top for any given problem, but rather one apparently chosen by absolute randomness.
Respectfully, i think that mostly happens when people reviewing the solution space don't understand the problem fully. Often the requirements differ from what people think they are, and as a result the winner seems random because they don't understand the actual requirements.
bigfatkitten
D-Bus came to prominence because of its association with GNOME, which has in turn has remained relevant mostly because of its association with Red Hat.
abenga
Most of the time, there is usually no "most meritorious", just something that is elsewhere on the "trade-off space" than the person speaking would like. I usually dismiss everybody who so snidely and arrogantly dismisses results of other people's work(e.g. the OP article), like there was some _obviously_ correct solution that the people who worked on the widely accepted solution were too stupid or malicious to choose. They could not possibly have had other priorities or doing their best to get something working acceptably in a complex ecosystem with no central control, no! They are just dumber than you (or just plain malicious).
Y_Y
Worse is better, but meta, because the worst way of choosing is what wins
volf_
The world is filled with "good enough" solutions. If it has 80% of the functionally needed, it will be good enough for most use cases.
> the most meritorious solution never rises to the top
You know why? Because it was the best solution at the time that covered everything they needed. You can only complain about it because the initial problem was solved and people were able to move on to something else.
Does it work for what we need it to do? Yes? Ok. Now that we have settled this problem, we can continue on developing.
Meritocracy is only relevant to someone who has ideas but no desire or ability to actually structure the idea in such a way that would work in the world we find ourselves in today.
> Maybe D-Bus has something similar?
So you just commented here to say nothing but "dbus sucks because it isn't the best. I wonder if there are better options?".
tguvot
iirc it was developed as freedesktop project in order to create standard desktop bus to be used by everybody, as back in a day kde had it's own bus and gnome had another one.
supportengineer
There is definitely an elite cabal with its thumb on the scale here.
1718627440
> The GNOME project disagrees with this vulnerability report because, according to their stated security model, untrusted applications must not be allowed to communicate with the secret service.
> Applications sandboxed via Flatpak only have filtered access to the session bus.
While I see why they think this is a bad answer it really reminds me of this: https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31... . Also they did not cite the last statement in their quote and made screenshots, so the quotes are not copyable. Who the hell does that?
ottah
Wayland, thow shall not screenshot without root.
D-Bus, YOLo!
1718627440
I am not a fan of Wayland either, I rather want to be able to run programs from different users against the same application server. This works just fine on Xorg.
seba_dos1
Works just fine on Wayland as well. It's simply a Unix socket that you can set permissions for, it's even easier than X11 with its magic cookies.
BeetleB
> D-Bus was introduced by GNOME folks about 20 years ago. For software made only 20 years ago, as opposed to 40 like X, it's surprisingly almost equally as bad.
I dunno man. Emacs is awesome.
Gualdrapo
I don't think they implied that old software is always bad.
null
AshamedCaptain
Can't you guys stop reinventing the wheel every other day? I hate D-Bus like everyone else, even though at least it did bring project Utopia and all such crap. But even if I think it sucks I stay with it for the simple reason that the more alternatives you create the more you annoy other users WAY MORE than any benefit you bring them. D-Bus has been used everywhere from LG TVs to automotives, so at least it f*cking works.
Does it miss a spec? Write one.
Do you really want your secretsd or whatever to only be able to reply to whomever stored the secret? Make clients store a cookie or something and only reply if they prove ownership of it. But I have to ask : what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway. Or read its files in $XDG_CONFIG_DIR. You are just moving around who has the ultimate responsibility, and that looks like security theater. In addition, I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Etc. Etc.
antiloper
> Make clients store a cookie or something and only reply if they prove ownership of it
Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
> what the hell is your threat model here? The attacker is just going to ptrace firefox and read all the secrets anyway.
Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
> I _want_ other programs to be able to read secrets (e.g. keyring administrators, .netrc-style shared secrets, etc.)
Then don't use it? Secure defaults matter for most users.
> Do you hate a{sv}? If you propose JSON as alternative, you are going to make me laugh.
Find the *kwargs here: https://wayland.app/protocols/xdg-shell
Etc. etc. This isn't the 90s anymore.
AshamedCaptain
> Unix domain socket authentication is stronger and doesn't require storing cookies on the client side.
And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands.
> Which is why you can (and people do, e.g. flatpak) run applications where ptrace or global filesystem access is blocked. Which is why portals exist and why there shouldn't be a "get all secrets via dbus" escape hatch.
In which case they do not connect to the same D-Bus "bus", and the problem is again non-existent. See how flatpak sandoxing does it.
> Then don't use it? Secure defaults matter for most users.
Right until they notice they can no longer view the keyring contents, or any other stupid limitation most desktop users couldn't care about.
In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
> Find the *kwargs here: https://wayland.app/protocols/xdg-shell
Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
torginus
Since docker, we know how to do pretty good isolation (some of the tech is shared by Flatpak etc. sandboxes) - just put stuff into different namespaces with some auth api allowing processes to 'mount' the necessary stuff.
The closer you stick to the kernel security model, the more likely your app will be safe and performant, and the less likely other devs will reject it in favor of their hand rolled stuff.
ghusto
> In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
If I store my secrets in KWallet, which purports to _storage for secrets_, I absolutely do not expect every application on the desktop to have access to those secrets, whether I want to share them or not.
I can't believe you're suggesting this is sanely defensible.
jchw
> And pointless here, since everything runs under the same uid. You need to authenticate this is the same browser that stored this secret, not that this is the same uid (useless), or the same pid, or any other concept that unix domain socket authentication understands.
I disagree. With UNIX domain sockets it is absolutely possible to determine the PID of the process that you are talking to and use pidfd to validate where it is coming from. Would be entirely possible to use this for policy.
> In fact, if you do not need a shared secrets service, and your applications are containerized... why do you need a secrets IPC at all? Just let each program store its secrets in some of its supposedly private storage...
And how exactly does the app container service store something encrypted securely on disk? That's literally the point of a secrets service on a modern desktop. It usually gets keymatter in the form of a user password carried to it from PAM, in order to allow on-disk encryption without needing separate keyring passwords. (And yeah, sure, this could use TPM or something else to avoid the passwords, but the point is literally no different, it shouldn't be each application's job individually to manage their own way of getting secure storage, that's a recipe for data loss and confusion.)
> Much better to have a million non-extendable protocols competing with each other. To this day there are two protocols (at least) for exposing the address of the DbusMenu service of a surface, one for gnome-shell and one for kwin. So much for the uglyness of X atoms. And this has nothing really to do with the design of the IPC mechanism itself...
That's a problem that occurs because the protocols have multiple distinct implementations. Most of the dbus services don't have to deal with that problem at all. (And the ones that do, tend to have problems like this. There are plenty of weird incompatibilities with different XDG desktop portal implementations.)
I'm pretty sure the point of bringing up xdg-shell is because the new bus is inspired by the Wayland protocol. For all of the incessant bitching about Wayland online, Wayland protocols are only about 1000x nicer to use than dbus. You can actually do decent code generation for it without having to have like 5 competing ways to extend the XML to add basic things like struct member annotations (and then have things like Qt's own DBus code generator unable to actually handle any real DBus service definitions. Try throwing the systemd one at it, doesn't fucking work. The code doesn't even compile.)
crest
The funny/sad detail is that the 80s (at the latest) already solved the problem. Have a look as XDR and Sun RPC. It has both strongly typed APIs and versioning built in. You would have to come up with your authentication mechanism for applications e.g. have them send a cookie file (descriptor).
blablabla123
This is the first time I hear that anyone hates D-Bus. I always saw it as a global API Bus that Apps can register to and which enables some sort of interoperability and automation. After all it can even be used from Bash. What is bad about this?
The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus.
Also I'm puzzled that Polkit hasn't been mentioned even once.
throw_await
The architecture is fundamentally broken when you are using multiple window managers / desktop environments https://github.com/dunst-project/dunst/issues/363
null
vanviegen
> The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything.
The world is moving towards sandboxed applications (through flatpak and friends) more and more. As per the OP, this is one of the things holding sandboxing back.
LtWorf
There's sandbox escapes daily since decades. It doesn't work.
dolmen
Check varlink, an alternative to D-Bus defined in the SystemD world.
ahartmetz
Nah, fuck that one in particular. DBus was too type-unsafe? Why not use JSON then, right? Right?!
craftkiller
> The security aspect seems also a bit funny to me. After all the average Desktop has most data in the home directory, so every application can read everything. That's not the fault of D-Bus.
Those secret stores (gnome-keyring/kwallet) store the secrets encrypted on disk, so every application can read the encrypted secrets but only the secret store has the encryption key to decrypt them. This is held in memory, not on disk.
Lammy
> Does it miss a spec? Write one.
FreeDesktop-dot-Org would not accept one from the author if he did:
torginus
I am puzzled by this comment - hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox? That's literally what stuff like Flatpak xdg-desktop-portal and Wayland isolation are built around.
And maybe its time for a reinvention anyway? IPC and efficient and portable formats are very mature nowadays, with protobuf, flatbuffers etc. and the general model of the internet is based around service location, and stuff talking to each other.
I'm kida curious why they didn't go with Unix Sockets in the first place, with named pipes in memory carrying the message transport.
seba_dos1
> hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox?
Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
smaudet
I've never had much luck with it either. A lot of the same pain points as the author.
As for it being used everywhere, sure, we had some bad SOAP stuff being used everywhere at one time, but that's not a good thing...
Regarding secrets etc.. on the one hand, yeah it's not much to worry about people with access to your machine reading stuff on your machine, buut*, it's kinda dumb to have stuff encrypted and left around for a public unsecured protocol. The solution would be, for apps that need security, don't use dbus.
If the API was less loosey goosey (self documentating, not so open ended, less awkward), I agree it's fine for applications at the same level of trust to all access the same thing.
The problem is more random scripts off the internet using browser apis to read stuff out of local storage containers. Forcing local containers to explicitly allow such access, and yes, using a non-dbus protocol, would be a preferred method, while not requiring overly complex authentication schemes locally...
Otherwise the main change I would have made would be to explicitly allow applications to access the bus, vs just a random app having access by virtue of running in memory...
agumonkey
I may be naive, but why not adopt the browsers api development model. 90% shared core apis, experimental ones, for a few years it seems that every group can work on its code without breaking things for user much while new ideas coming regularly.
shevy-java
How does it work exactly? I mean, the premise here is:
"it f*cking works"
Can we objectify this claim made here?
javier2
Perhaps the SecretManager deserves some extra attention, but I concur. We worked long enough on this, please dont split whats left of the linux desktop...
egorfine
I believe someone from systemd should reimplement d-bus in rust. This way we can have all the things we hate in a single instance.
klooney
https://varlink.org/ systemd already has
egorfine
Problem is, varlink has been created to alleviate the pain while what I'm looking for here is even more suffering. Perhaps add AI and MCP into the mix. At kernel level with hard dependency on sudo-rs. And local RPC should be blockchain-based.
>I've decided to take matters into my own hands. I am writing a new bus.
Why not reuse Binder which has been to deployed to billions of devices, being a core part of a serious OS, with many many more developers who understand it compared to dbus.
You would probably want to write your own service manager, but you can reuse hardened stuff that already exist.