Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932835AbbGJOVY (ORCPT ); Fri, 10 Jul 2015 10:21:24 -0400 Received: from mondschein.lichtvoll.de ([194.150.191.11]:48158 "EHLO mail.lichtvoll.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932783AbbGJOUr convert rfc822-to-8bit (ORCPT ); Fri, 10 Jul 2015 10:20:47 -0400 From: Martin Steigerwald To: David Herrmann Cc: Stephen Smalley , Greg KH , Daniel Mack , Djalal Harouni , lkml , LSM , Paul Osmialowski , Casey Schaufler , Paul Moore Subject: Re: kdbus: credential faking Date: Fri, 10 Jul 2015 16:20:44 +0200 Message-ID: <2655319.HiHStWqHEi@merkaba> User-Agent: KMail/4.14.10 (Linux/4.1.0-tp520-btrfstrim-pstatetrace+; KDE/4.14.2; x86_64; git-3a40aa3; 2015-06-28) In-Reply-To: References: <559EBCC0.7040604@tycho.nsa.gov> <559FC7DD.8060507@tycho.nsa.gov> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="utf-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2113 Lines: 50 Am Freitag, 10. Juli 2015, 15:43:08 schrieb David Herrmann: > Hi Hi, > On Fri, Jul 10, 2015 at 3:25 PM, Stephen Smalley > 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. Wow, do I get this right, that this credential faking – I do think that the last two words are already completely sufficient to show the insanity of it at least when I apply something to it that is commonly called common sense, credential *what*? – is just for supporting something that is broken in userspace already? I do get the "never break userspace" mantra for anything *already* implemented in the kernel. But this is more like "userspace is broken, lets port it into the kernel and keep the brokenness while doing so thus setting the brokenness in stone" due to the first mantra. I did not look at the actual code, but from the mere reading of this, I shudder. I am happy that you digged this out of the larger thread with a descriptive thread title, so that this may get some attention, Stephen. Ciao, -- Martin -- 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/