The kdbuswreck

Posted Apr 23, 2015 23:04 UTC (Thu) by jspaleta (subscriber, #50639)
In reply to: The kdbuswreck by drag
Parent article: The kdbuswreck

i'm not seeing how kdbus mandates caps usage for all of eternity.

Here's my understanding that right now with the current patches
receiver decided if it needs to have caps info or not
sender decides if it wants to send over caps.

If they agree recv and sender get to talk via the bus. If they don't.. bus doesn't relay mesgs.

If in the future every single receiver and sender on the bus decided they no longer needed to care about caps they can just stop asking for that metadata to be sent over the bus. Right?

The kdbuswreck

Posted Apr 23, 2015 23:23 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

If the kernel API says that it passes caps, it is _really_ hard to change that later without breaking something in userspace that depends on it.

This is one of the big reasons people are unhappy with kdbus, it locks a lot of dbus specific policies into the kernel API

The claim is that the only thing that should talk to it is libdbus, but we've already seen that such a policy doesn't work against the userspace dbus, so why would it work against kdbus?

The kdbuswreck

Posted Apr 23, 2015 23:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

DBUS is extensible, so in future it's certainly possible to pass additional capabilities via custom methods. The old userspace simply won't be able to use it, but that's not a big deal.

It all seems like a storm in a teacup, the current capabilities are used only for very special actions like rebooting or manipulation of system services. Basically, they are more-or-less a direct replacement of "if (sender_uid == 0)".

The kdbuswreck

Posted Apr 30, 2015 10:17 UTC (Thu) by metux-its (guest, #102293) [Link]

Actually, I never understood why tiny side cases like reboots need all that complexity.

Anybody noticed that we already have per-process namespaces ?
Oh, and we've got file permission flags since aeons.

Why not just giving things like the shutdown/reboot service their
own communication channel (ie. socket), which is only made available
to certain users or processes ? Either via perms or mounts, or by
some key authentication ?

Anybody had a look at Plan9 ?
It really could be so simple ...