Starting the kdbus discussions

[Yang Chengwei]

On Thu, Jan 09, 2014 at 05:39:06PM +0800, Kay Sievers wrote:
> On Thu, Jan 9, 2014 at 12:56 AM, Tyler Hicks <tyhicks at canonical.com> wrote:
> > On 2014-01-08 07:04:48, Greg KH wrote:
> >> On Wed, Jan 08, 2014 at 08:12:43AM -0500, Marc Deslauriers wrote:
> >> > On 14-01-08 03:51 AM, Lennart Poettering wrote:
> >> > > On Tue, 07.01.14 15:24, Tyler Hicks (tyhicks at canonical.com) wrote:
> >> > >
> >> > >> Hi Lennart! I've added Greg to cc since John Johansen and I spoke with
> >> > >> him about this in a hallway at Plumbers last year.
> >> > >>
> >> > >> On 2014-01-02 18:08:42, Lennart Poettering wrote:
> >> > >>> I am sorry, but to make this very clear: this is explicitly not an
> >> > >>> option. There will not be a payload parser for kdbus in the kernel, as
> >> > >>> long as the four developers who are working on it have any say. The
> >> > >>> entire design is based on the concept that the payload is irrelevant to
> >> > >>> the kernel, and routing is done only according to the metadata we
> >> > >>> attach. This is a fundamental design decision of kdbus, and the four of
> >> > >>> us (Kay, Daniel, Greg and I) will refuse this.
> >> > >>
> >> > >> I agree that parsing the payload in the kernel is not something that we
> >> > >> should do. However, I do think that there are some important metadata
> >> > >> fields hidden away in the opaque sd_bus_message that should be exposed
> >> > >> to the kernel by way of moving them to the kdbus_msg.
> >> > >>
> >> > >> I'm proposing that the following fields be moved to the kdbus_msg:
> >> > >>
> >> > >>  - message type
> >> > >>  - destination
> >> > >>  - sender
> >> > >
> >> > > These three you have anyway, in one way or another. (or can mostly
> >> > > reconstruct from the data available to the kernel, since the kernel can
> >> > > distuingish method calls from method replies and broadcast signals --
> >> > > though you cannot distuingish methods replies from method errors).
> >> > >
> >> > >>  - path
> >> > >>  - interface
> >> > >>  - member
> >> > >
> >> > > Nope. This is really not how this is supposed to work. These concepts
> >> > > are opaque to the kernel on purpose.
> >> >
> >> > So you're not willing to change any of your design to cope with the community's
> >> > requirements?
> >>
> >> A meta comment here.
> >>
> >> That's not how development works.  Look at the Samsung developer's use
> >> of kdbus as an example of how to do things.  I kept telling them to not
> >> use kdbus yet as it wasn't ready, but did they listen to me?  No, they
> >> went and used it, and then, when they had issues with the code, they
> >> sent patches resolving it for them.
> >>
> >> Development works with code, not "could you please change your design to
> >> help with our single-use problem that isn't even implemented for dbus
> >> today".  Try implementing the above in the kdbus code and see how
> >> intrusive, and unneeded for the rest of the world to understand why we
> >> are objecting to this.  Maybe we are wrong, and it isn't, but we will
> >> never really know until you do the work...
> >
> > That's a good point. I threw my proposal out there after Lennart invited
> > the discussion on kdbus but I should have made it clear that I fully
> > intended to do the work myself.
> >
> > I'll start getting patches together and see if I hit any snags. I'll
> > also try my best to limit the added overhead on other kdbus users that
> > don't need this sort of functionality.
> 
> To be clear, at this point in time there will be no such change merged
> into kdbus. Regardless of existing patches or not; so please be aware
> that your work is unlikely to get merged.
> 
> Kdbus should not expose the interface/object path/member properties,
> they are part of the message payload, meaningless to the kernel
> transport and should stay opaque as they are.
> 
> This is just because we think it is technically wrong to do this on
> the kernel side, there is no other conspiracy going on.

I see the most argumentive thing is that kdbus is trying to play both a
transport (just like socket transport in dbus) role and a bus daemon
role.

To be a transport, yes, it doesn't make sense to parse the payload.

However, while to be a bus daemon like thing in kernel, kdbus works as a
message router, a central controller, is the first place to take route
rules into place I can tell, most straightforward.

I think it's reasonable to argue the extra burden this change bring
to application developers, as you said, they should adopt some security
policy themselves.

Meanwhile, as I understand, the *temporary* solution is connect to bus
proxy, this just cancel out some of the kdbus performance gain. And make
the whole picture more complicated, so one day all the application
developer must sign up to the pain to adopt their own security policy to
work with kdbus. Otherwise, bus proxy will become another dbus-daemon
which is targeted to be replaced by kdbus I think.

Anyway, bus policy isn't a part of DBus spec, but a part of the
reference dbus-daemon implementation.

--
Thanks,
Chengwei

> 
> Thanks,
> Kay
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20140110/2549fe4d/attachment.pgp>