Ubuntu 23.10 Looks Like It Will Switch To Using Dbus-Broker

[Weasel]

You need to read those posts again you missed something

https://dvdhrm.github.io/rethinking-the-dbus-message-bus/

Linux Only section here.


dbus-deamon was written to use Posix API as much as possible. Weasel you should know what I think of that broken bit of works that the Posix API is when it comes to these multi process problems The race conditions are removed from dbus-broker by being Linux only and using Linux only API not any form of feature set change.

This has nothing to do with anything. That's just the dbus-broker daemon implementation using Linux-only features. A library could also use "Linux-only" features if it wanted to, or needed to.

[oiaohm]

This has nothing to do with anything. That's just the dbus-broker daemon implementation using Linux-only features. A library could also use "Linux-only" features if it wanted to, or needed to.

That the problem. dbus daemon development actively avoided Linux only features even when they are need were dbus-broker has no issue using them. Like the dbus deamon service failure to start race conditions that can happen. Using platform particular code here fixes the problem. dbus-broker has platform particular code so the race condition does not exist but dbus-deamon try to use Posix only.

Same problem effects dbus deamon as the issues that effect sysvinit on Linux.. Core part of dbus is that the daemon is in fact doing service management or working with the platform service mangement.

Weasel having a rule not to use platform only features where possible to be cross platform does create some horrible problems. Name one service management solution that works correctly cross platform without having blocks of platform unique code performing the service management. Yes the race conditions implementing dbus with dbus daemon almost all trace back to service management things that need platform unique code to fix correctly.

[Weasel]

That the problem. dbus daemon development actively avoided Linux only features even when they are need were dbus-broker has no issue using them. Like the dbus deamon service failure to start race conditions that can happen. Using platform particular code here fixes the problem. dbus-broker has platform particular code so the race condition does not exist but dbus-deamon try to use Posix only.

Same problem effects dbus deamon as the issues that effect sysvinit on Linux.. Core part of dbus is that the daemon is in fact doing service management or working with the platform service mangement.

Weasel having a rule not to use platform only features where possible to be cross platform does create some horrible problems. Name one service management solution that works correctly cross platform without having blocks of platform unique code performing the service management. Yes the race conditions implementing dbus with dbus daemon almost all trace back to service management things that need platform unique code to fix correctly.

I mean, I agree. I don't mind platform specific features at all. It could likely still be simplified to a pure library only without any daemon mediating it, but at this stage, not without breaking (some of) the ABI, so it's too late I think.

[oiaohm]

I mean, I agree. I don't mind platform specific features at all. It could likely still be simplified to a pure library only without any daemon mediating it, but at this stage, not without breaking (some of) the ABI, so it's too late I think.

It where with a library are you going to do the authorization yes the the polkit bits and the fact dbus service can be starting items above your users level privilege.

binder with android only secure when using selinux MAC security.

Library to cover the role of dbus fully would require alterations at kernel level so user can have process started at higher privilege with authentication. Linux kernel has MAC and DAC this would be something different again. MAC with means to ask user for approval is not pure MAC any more.

Dbus/polkit technically works around limitation of Linux/BSD kernel security system.

Weasel yes lot more platform specific features need to make dbus functionality just a library. kdbus that failed was attempting to add lots of features.

dbus/polkit might be good enough solution.

Mediating the IPC is required once you have security on the IPC.