Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932085AbbDOIgD (ORCPT ); Wed, 15 Apr 2015 04:36:03 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:60933 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752992AbbDOIf5 (ORCPT ); Wed, 15 Apr 2015 04:35:57 -0400 Date: Wed, 15 Apr 2015 10:35:54 +0200 From: Greg Kroah-Hartman To: John Stoffel Cc: Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Jiri Kosina , "linux-kernel@vger.kernel.org" , Daniel Mack , David Herrmann , Djalal Harouni Subject: Re: [GIT PULL] kdbus for 4.1-rc1 Message-ID: <20150415083554.GC16381@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <21805.29994.968937.364993@quad.stoffel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21805.29994.968937.364993@quad.stoffel.home> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 8485 Lines: 157 On Tue, Apr 14, 2015 at 04:14:34PM -0400, John Stoffel wrote: > >>>>> "Greg" == Greg Kroah-Hartman 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 > >> 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 > >> >> 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 > >> >> >> 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 'org.foo.bar' and > >> >> 'org.blah.baz', and the policy database allows > >> >> 'org.blah.baz' to be talked to by WORLD, then this > >> >> permission is also granted to 'org.foo.bar'. 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 -- 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/