Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1181730 > unrolled thread

Re: kdbus: credential faking

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: kdbus: credential faking Casey Schaufler <casey@schaufler-ca.com> - 2015-07-10 18:30 +0200
    Re: kdbus: credential faking Alex Elsayed <eternaleye@gmail.com> - 2015-07-10 18:40 +0200
      Re: kdbus: credential faking Casey Schaufler <casey@schaufler-ca.com> - 2015-07-10 19:50 +0200

#1181730 — Re: kdbus: credential faking

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. 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1181735

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.

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

[toc] | [prev] | [next] | [standalone]

#1181804

On 7/10/2015 9:30 AM, Alex Elsayed wrote:
> 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.

OK, I stand corrected. A bit surprised, but corrected.

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

That's a design choice, and I expect that performance is going to matter
more to Java than to Haskell. I have not got a lot of experience with
Haskell programmers, but I do with the Java variety. The Java folks are
going to want the 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.
> ...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.

That's a whole different thread. If dbus performance got fixed there'd be
no selling point for kdbus. 

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

Sorry, but there are no unicorns dancing on that rainbow.
It sounds good, but you always hit outliers that use things
in a perverse or unnatural, but technically permitted way.
The "first, do no harm" mantra may work when you're carving
on someone's spleen, but it is pretty destructive when you're
building significant software infrastructure.

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web