Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754223AbbDNUPO (ORCPT ); Tue, 14 Apr 2015 16:15:14 -0400 Received: from mailrelay4.lanline.com ([216.187.10.25]:29268 "EHLO mailrelay4.lanline.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752775AbbDNUPG (ORCPT ); Tue, 14 Apr 2015 16:15:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21805.29994.968937.364993@quad.stoffel.home> Date: Tue, 14 Apr 2015 16:14:34 -0400 From: "John Stoffel" To: Greg Kroah-Hartman 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 In-Reply-To: <20150414192357.GA6107@kroah.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> X-Mailer: VM 8.2.0b under 23.4.1 (x86_64-pc-linux-gnu) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 7243 Lines: 135 >>>>> "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. 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. 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. John -- 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/