Re: [GIT PULL] kdbus for 4.1-rc1

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Tue, Apr 14, 2015 at 04:14:34PM -0400, John Stoffel wrote:
> >>>>> "Greg" == Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> 
> Greg> On Tue, Apr 14, 2015 at 11:57:22AM -0700, Andy Lutomirski wrote:
> >> On Tue, Apr 14, 2015 at 10:50 AM, Greg Kroah-Hartman
> >> <gregkh@linuxfoundation.org> wrote:
> >> > On Mon, Apr 13, 2015 at 02:01:21PM -0700, Andy Lutomirski wrote:
> >> >> On Mon, Apr 13, 2015 at 1:45 PM, Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> > On Mon, Apr 13, 2015 at 01:13:26PM -0700, Andy Lutomirski wrote:
> >> >> >> On Mon, Apr 13, 2015 at 12:03 PM, Greg Kroah-Hartman
> >> >> >> <gregkh@linuxfoundation.org> wrote:
> >> >> >> > The following changes since commit 9eccca0843205f87c00404b663188b88eb248051:
> >> >> >> >
> >> >> >> >   Linux 4.0-rc3 (2015-03-08 16:09:09 -0700)
> >> >> >> >
> >> >> >> > are available in the git repository at:
> >> >> >> >
> >> >> >> >   git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git/ tags/kdbus-4.1-rc1
> >> >> >> >
> >> >> >> > for you to fetch changes up to 9fb9cd0f4434a23487b6ef3237e733afae90e336:
> >> >> >> >
> >> >> >> >   kdbus: avoid the use of struct timespec (2015-04-10 14:34:53 +0200)
> >> >> >> >
> >> >> >> > ----------------------------------------------------------------
> >> >> >> > kdbus for 4.1-rc1
> >> >> >> >
> >> >> >> > Here's the kdbus pull request for 4.1-rc1.
> >> >> >> >
> >> >> >> > It's been under development for many years now, and been in linux-next
> >> >> >> > for many months, and has undergone loads of testing a review and even a few
> >> >> >> > good arguments.  It comes with full documentation and tests.
> >> >> >> >
> >> >> >> > There has been a few complaints about the code, notably from people who
> >> >> >> > don't like the use of metadata in the bus messages.  That is actually
> >> >> >> > one of the main features here, as we can get this data in a secure and
> >> >> >> > reliable way, and it's something that userspace requires today.  So
> >> >> >> > while it does look "odd" to people who are not familiar with dbus, this
> >> >> >> > is something that finally fixes a number of almost unfixable races in
> >> >> >> > the current dbus implementations.
> >> >> >>
> >> >> >> While I generally like the concept of having a better in-kernel IPC
> >> >> >> mechanism, after some consideration I don't think this belongs in the
> >> >> >> kernel in its current form.  Here's why.
> >> >> >>
> >> >> >> First, the naming is counterintuitive.  There are "endpoints", but you
> >> >> >> don't send messages to endpoints.  In fact, an basic kdbus setup will
> >> >> >> have exactly one endpoint AFAICT.  Wtf?  This makes talking about it
> >> >> >> awkward.
> >> >> >
> >> >> > Did you read the documentation?  We've been over this before, and it
> >> >> > should all be addressed in the documentation based on this coming up.
> >> >> >
> >> >> >> A lot of the design seems to be to violate the concept of "mechanism,
> >> >> >> not policy".  Kdbus is very much a port of userspace dbus to the
> >> >> >> kernel, and it appears to be a port designed to preserve some
> >> >> >> questionable design decisions instead of learning from them.
> >> >> >>
> >> >> >> For example, kdbus sticks a whole policy database in the kernel, but
> >> >> >> that policy database (AFAICT -- holy crap it's overcomplicated) is
> >> >> >> *not* a simple set of rules like "if A then allow B".  Instead it has
> >> >> >> really weird dependencies not on what name you're sending to but on
> >> >> >> what *other* names the thing you're sending to has.  Sorry, but this
> >> >> >> way lies (a) the inability for a large set of developers to understand
> >> >> >> what's going on and (b) security bugs.  Also, the result probably
> >> >> >> can't be reused as part of a non-legacy-filled sensible design
> >> >> >
> >> >> > What policy database?  Matching messages to subscribers?  That's the
> >> >> > same type of "database" that other ipc subsystems need/want, there's
> >> >> > nothing radical here.
> >> >>
> >> >> Let me quote from the latest version of the kdbus docs:
> >> >>
> >> >>       Note that TALK access is checked against all names of a connection. For
> >> >>       example, if a connection owns both <constant>'org.foo.bar'</constant> and
> >> >>       <constant>'org.blah.baz'</constant>, and the policy database allows
> >> >>       <constant>'org.blah.baz'</constant> to be talked to by WORLD, then this
> >> >>       permission is also granted to <constant>'org.foo.bar'</constant>. That
> >> >>       might sound illogical, but after all, we allow messages to be directed to
> >> >>       either the ID or a well-known name, and policy is applied to the
> >> >>       connection, not the name. In other words, the effective TALK policy for a
> >> >>       connection is the most permissive of all names the connection owns.
> >> >>
> >> >> In my humble opinion, this paragraph speaks for itself.  The design is
> >> >> bad, full stop.
> >> >
> >> > First off, thanks for reading the docs, I appreciate that.  But realize
> >> > also, that this is straight from the D-Bus spec.  We aren't doing
> >> > anything "radical" here, this is what your desktop uses that you are
> >> > typing your email from.
> >> >
> >> > Yes, it's an unfortunate design, but one that we are all stuck with
> >> > (think of it as having to implement code for horrid hardware that you
> >> > have to get to work properly.)
> >> 
> >> I agree.  You've sent a pull request for an unfortunate design.  I
> >> don't think that unfortunate design belongs in the kernel.  If it says
> >> in userspace, then user programmers could potentially fix it some day.
> 
> Greg> You might not like the design, but it is a valid design.  Again, we
> Greg> don't refuse to support hardware that is designed badly.  Or support
> Greg> protocols we don't necessarily like, that's not the job of a kernel or
> Greg> operating system.
> 
> Greg> And here's Havoc's response as to why actually, this is a good design:
> Greg> 	http://lists.freedesktop.org/archives/dbus/2015-April/016651.html
> 
> This is an interesting discussion, and one thing that sticks out to me
> is the comments in the URL above talking about how clients are
> supposed to use a generic name to bind to a resource, but actually do
> a lookup to get the specific name, and then bind to THAT.
> 
> So the security concerns raised by Andy do seem to make sense, in that
> either security needs to be the same across all names of a service, so
> that you don't have problems with varying levels once people have
> connected.  In terms of the X11 analogy, if I have someone connect,
> and then I do 'xhost -' it removes all access.  It's not dependent on
> whether I'm bound to a specific or general service.  
> 
> So the security aspect really needs to be that the most restrictive
> takes precedence, not the other way around.  

But look at how dbus handles this, isn't this done in the correct way?

> And after having read a bunch of the docs, looked at the FAQ, etc;
> it's still no clearer to me what DBUS and KDBUS provides that's all so
> important or critical.  Sure, it might be nice to have, but that's ok.

The first email I wrote here explains all of this, are those not valid
uses for such a service that the kernel can provide?

> So I think that's the steps people need to take, give concrete example
> of how DBUS is better than anything else out there and won't cause
> more problems down the line.

D-Bus has been around for over 10 years now, and was the result of many
failed attempts to do something much like this (COM, DCOM, CORBA, and a
few others).  The developers involved had lots of experience in this
area, and created a solution that ended up working very well for the
problem domain.  So well that all other competing technologies in that
area were obsoleted and abondonded and everyone has moved to D-Bus as it
solves the problems they have in a correct manner.

The reason nothing else has come along might just be because nothing
else _needs_ to come along, D-Bus solves the need.

So unless you see a technical reason why the proposed code is somehow
not correct, I don't understand your complaint.

thanks,

greg k-h