Re: kdbus: credential faking

[Alex Elsayed <eternaleye@gmail.com>]

Casey Schaufler wrote:

> On 7/10/2015 7:57 AM, Alex Elsayed wrote:
>> Stephen Smalley wrote:
>>
>>> On 07/10/2015 09:43 AM, David Herrmann wrote:
>>>> Hi
>>>>
>>>> On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley <sds@tycho.nsa.gov>
>>>> wrote:
>>>>> On 07/09/2015 06:22 PM, David Herrmann wrote:
>>>>>> To be clear, faking metadata has one use-case, and one use-case only:
>>>>>> dbus1 compatibility
>>>>>>
>>>>>> In dbus1, clients connect to a unix-socket placed in the file-system
>>>>>> hierarchy. To avoid breaking ABI for old clients, we support a
>>>>>> unix-kdbus proxy. This proxy is called systemd-bus-proxyd. It is
>>>>>> spawned once for each bus we proxy and simply remarshals messages
>>>>>> from the client to kdbus and vice versa.
>>>>> Is this truly necessary?  Can't the distributions just update the
>>>>> client
>>>>> side libraries to use kdbus if enabled and be done with it?  Doesn't
>>>>> this proxy undo many of the benefits of using kdbus in the first
>>>>> place?
>>>> We need binary compatibility to dbus1. There're millions of
>>>> applications and language bindings with dbus1 compiled in, which we
>>>> cannot suddenly break.
>>> So, are you saying that there are many applications that statically link
>>> the dbus1 library implementation (thus the distributions can't just push
>>> an updated shared library that switches from using the socket to using
>>> kdbus), and that many of these applications are third party applications
>>> not packaged by the distributions (thus the distributions cannot just do
>>> a mass rebuild to update these applications too)?  Otherwise, I would
>>> think that the use of a socket would just be an implementation detail
>>> and you would be free to change it without affecting dbus1 library ABI
>>> compatibility.
>> Honestly? Yes. To bring up two examples off the bat, IIRC both Haskell
>> and Java have independent *implementations* of the dbus1 protocol, not
>> reusing the reference library at all - Haskell isn't technically
>> statically linked, but its ABI hashing stuff means it's the next best
>> thing, and both it and Java are often managed outside the PM because for
>> various reasons (in the case of Haskell, lots of tiny packages with lots
>> of frequent releases make packagers cry until they find a way of
>> automating it).
> 
> There is absolutely no reason to expect that these two examples don't have
> native kdbus implementations in the works already.

The Haskell one, at least, does not. I checked.

> 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.

Or, you know, avoiding the hassle of building and/or linking to code in 
another language via FFI. That's my recall of the primary reason for the 
Haskell one - and I don't think it's any coincidence that the two pure 
reimplementations are in managed-but-compiled languages.

> 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.

...sure, if performance was the object. But it went through the old D-Bus 
daemon either way, so I'm rather dubious of your assertion - whether due to 
being in userspace or just poor implementation, it's no speed daemon so to 
speak.

> Backward compatibility shims/libraries/proxies only work when it's the
> rare and unimportant case requiring it. If it's the common case, it won't
> work. If it's the important case, it won't work. If kdbus is worth the
> effort, make the effort.

They also work if they require no configuration or effort from the legacy 
side, allowing those who need the (possibly rare *but also* important) 
benefits of the new system to benefit without causing harm to others.