linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150421134836.GA9895@kroah.com>
Date:	Tue, 21 Apr 2015 15:48:36 +0200
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Olivier Galibert <galibert@...ox.com>
Cc:	Andy Lutomirski <luto@...capital.net>,
	Richard Weinberger <richard@....at>,
	David Herrmann <dh.herrmann@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Jiri Kosina <jkosina@...e.cz>,
	Al Viro <viro@...iv.linux.org.uk>,
	Borislav Petkov <bp@...en8.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Tom Gundersen <teg@...m.no>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Tue, Apr 21, 2015 at 03:18:35PM +0200, Olivier Galibert wrote:
> On Tue, Apr 21, 2015 at 12:31 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> > Bringing up SCM_RIGHTS means that this is not going to be a bus system
> > at all.  One principal design goal is to _not_ have peer-to-peer
> > connections between all communicating parties, but rather one connection
> > to a central component.  If that component is not in the kernel, it has
> > to be a userspace deamon, which in turn has all of the issues that
> > dbus-daemon currently has.
> 
> You're not making sense there.  If there is no daemon, then you're
> peer-to-peer, because there's no central component.

The kernel is the central component, as implemented in the patches.

> If you consider the kernel the central component, then peer-to-peer is
> almost impossible by definition.

Um, no, they go through the kernel for that model as well, same
interface, it just depends on the type of message that you are sending
as to who the recipients are (single or more than one.)

> It seems that almost everybody here thinks that the plumbing (e.g.
> transmitting messages in-order with multicasting) should be separated
> from the policy (who communicates with who), possibly leveraging the
> packet filtering infrastructure to implement the decided policy.  What
> it is you reject about that point of view, which seems relatively
> normal when you think about building a collection of useful tools?

The plumbing is "separated" from the policy in that they are different
data structures, but you have to have the policy in order to know who to
connect with whom, otherwise it just doesn't work.

How would packet filtering work here for this type of decision making?
That's a much more complex interface than what we have implemented,
don't you agree?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/