Re: kdbus: credential faking

[Casey Schaufler]

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

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.

>
> <snip>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/