KDBUS Is Being Removed From Fedora, Could Be A While Before Being Mainlined

[phoronix]

Phoronix: KDBUS Is Being Removed From Fedora, Could Be A While Before Being Mainlined

In somewhat of an embarrassing move and indicating that KDBUS likely won't be proposed for Linux 4.4, this in-kernel IPC mechanism is being temporarily stripped out of Fedora...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Drops-KDBUS

[You-]

I don't see why its an embarrasment... its a process of development where concepts and implementations often need to be refined. Usage in places like rawhide probably helped in highlighting issues that needed to be addressed.

[Drago]

I don't see why its an embarrasment... its a process of development where concepts and implementations often need to be refined. Usage in places like rawhide probably helped in highlighting issues that needed to be addressed.

Absolutely! Software development is much more evolution, rather than revolution. Personally I am waiting stable KDBUS with excitement.

[Naib]

I don't see why its an embarrasment... its a process of development where concepts and implementations often need to be refined. Usage in places like rawhide probably helped in highlighting issues that needed to be addressed.

Its an embarrement from two perspectives.
For quite some time there has been specific and fundemental concerns with kdbus and they have been raised on the ml. These have just been ignored by kdbus developers.. The concerns were valid and were neither disputed or corrected JUST ignored. The entire security this was a farse...

http://lkml.iu.edu/hypermail/linux/kernel/1507.1/01758.html

A: kdbus can fake credentials
B: That's because it needs to in order to support dbus1 apps
A: But it's a security risk
B: Won't someone think of the applications?!!?! There are millions of legacy dbus1 apps that we need to support with kdbus
C: "But this is more like "userspace is broken, lets port it into the kernel and keep the brokenness while doing so thus setting the brokenness in stone" due to the first mantra." / "ok, we have some userspace functionality that we need to be compatible to it, but in order to do this, we need to do something in the kernel that is broken by design"
A: why don't you just use a socket for dbus1 compatibility?
D: But we'll break java and haskell since they depend on dbus1
E: "If kdbus is better (or even just cooler or more popular) the change over will be swift and painless. The *only* reason that won't be true is if the benefits of kdbus are unclear, in which case it shouldn't be adopted" / "There are so many ways uids are being (miss/ab)used on Linux systems these days that the idea of trusting a bus just because its non-root uid is listed in a table somewhere (or worse, coded in an API) is asking for exploits."
E: "There is absolutely no reason to expect that these two examples don't have native kdbus implementations in the works already. That's the risk you take when you eschew the "standard" libraries. Further, the primary reason that developers deviate from the norm is (you guessed it!) performance. The proxy is going to kill (or at least be assumed to kill) that advantage, putting even more pressure on these deviant applications to provide native kdbus versions."
B: Please tell me how it can be exploited since I don't know any better even though I'm trying to force this on everyone
B: All of this is built on the assumption that you can trust UIDs and I can't imagine why you'd want to talk to another UID's bus
A: If you assume this, you can't be sure that user space won't violate it in the future. The credential metadata is apparently superfluous... but I guess we'll have to allow the credential faking because dbus1

The only excuse for justifying the break in the security was "I wish we could, but we can't break programs that are currently running
today, that would be pretty mean."

Then there is systemd attempting to bypass the kernel dev process and advising other distro's to follow rawhide direction with applying the patch.

Sure testing is expected & bugs are expected BUT when there was soo many concerns raised and not addressed... its bad form of both systemd and kdbus devs to state it was in a good enough state to not only force enable support in systemd but equally advise other distro's to apply the patch.

What if they did... kdbus already broke their own abi and that was 4.2 to 4.3 ... if they shipped it into the wild and people started using it. ...
reviews exist for a reason and the outcome should be taken into concideration

[duby229]

Absolutely! Software development is much more evolution, rather than revolution. Personally I am waiting stable KDBUS with excitement.

Of course, but kdbus usage will end up being near ubiquitous. It does way too much. They need to slim it down and strip out a whole hell of a lot. I'm not saying a good IPC isn't needed, but kdbus isn't that.

[vsteel]

There is NEVER a compelling enough reason to break security.

[yoshi314]

Kdbus looked ok on paper, but even short review it had on lkml exposed a lot of problems with it (and with dbus too). And it seems there are new problems coming up now.

its bad form of both systemd and kdbus devs to state it was in a good enough state to not only force enable support in systemd but equally advise other distro's to apply the patch.

said devs are not exactly known for good development practices (at least some of them). So i am not really surprised there.

The good thing in all this is that nothing in userspace that already uses kdbus, so it can be redesigned/rewritten.

[LubosD]

Is it true that kdbus' userspace library is part of systemd, hence this new IPC mechanism will only be available on systems with systemd?

[duby229]

Is it true that kdbus' userspace library is part of systemd, hence this new IPC mechanism will only be available on systems with systemd?

It is being developed by systemd devs. I don't think it would be too hard to get it working outside of systemd. But there is a lot of anti-systemd sentiment so it's probably unlikely that that it would happen until so many applications need it that it would have to be done. But chances are that those applications will just pull systemd in as a dependency. Much like how Gnome is treated on Gentoo right now.

[Ancurio]

Of course, but kdbus usage will end up being near ubiquitous. It does way too much. They need to slim it down and strip out a whole hell of a lot. I'm not saying a good IPC isn't needed, but kdbus isn't that.

All it does is exactly implement the dbus specification. What do you want to slim down?