From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755203AbbBBJfA (ORCPT ); Mon, 2 Feb 2015 04:35:00 -0500 Received: from svenfoo.org ([82.94.215.22]:34948 "EHLO mail.zonque.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753995AbbBBJe5 (ORCPT ); Mon, 2 Feb 2015 04:34:57 -0500 Message-ID: <54CF44B9.8000005@zonque.org> Date: Mon, 02 Feb 2015 10:34:49 +0100 From: Daniel Mack User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Arnd Bergmann , "Ted Ts'o" , Linux API , Michael Kerrisk , One Thousand Gnomes , Austin S Hemmelgarn , Tom Gundersen , Greg Kroah-Hartman , linux-kernel , David Herrmann , "Eric W. Biederman" , Djalal Harouni , Johannes Stezenbach , Christoph Hellwig Subject: Re: [PATCH 01/13] kdbus: add documentation References: <1421435777-25306-1-git-send-email-gregkh@linuxfoundation.org> <1421435777-25306-2-git-send-email-gregkh@linuxfoundation.org> <54BE5DC8.70706@gmail.com> <54BE9D08.7010804@zonque.org> <54BF805B.4000609@gmail.com> <54BFDAAA.50203@zonque.org> <54C0CE8A.5080805@gmail.com> <54C10DDC.9000503@gmail.com> <20150123160854.GA5210@kroah.com> <54C65346.5070504@gmail.com> <54C9F525.4040703@zonque.org> <54CA1CA2.9060005@zonque.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Andy, On 01/29/2015 01:09 PM, Andy Lutomirski wrote: > On Jan 29, 2015 6:42 AM, "Daniel Mack" wrote: >> As we explained before, currently, D-Bus peers do collect the same >> information already if they need to have them, but they have to do deal >> with the inherit races in such cases. kdbus is closing the gap by >> optionally providing the same information along with each message, if >> requested. > > In all these discussions, no one ever gave a decent example use case. > If a process drops some privilege, it must close all fds it has that > captured its old privilege. This has nothing to do with kdbus. kdbus does not implement any new concept here but sticks to what SCM_CREDENTIALS does on SOL_SEQPACKET. An application can get a file-descriptor from socket() or socketpair() and freely pass it around between different tasks or threads, but messages will always have the credentials attached that are valid at *send* time. SO_PEERCREDS, however, still reports the connect-time credentials, and kdbus provides exactly the same semantics and both ways of retrieving information. > I agree that the design seems to have improved to a state of being at > least decent, One reason for that is your feedback. Thanks for that again! > It's an optional feature that will get used, non-optionally, thousands > of times on each boot, apparently. Keep in mind that it's also a > scalability problem because it takes locks. If it ever gets used > thousands of times per CPU on a big thousand-core machine, it's going > to suck, and you'll have backed yourself into a corner. That's right, but again - if an application wants to gather this kind of information about tasks it interacts with, it can do so today by looking at /proc or similar sources. Desktop machines do exactly that already, and the kernel code executed in such cases very much resembles that in metadata.c, and is certainly not cheaper. kdbus just makes such information more accessible when requested. Which information is collected is defined by bit-masks on both the sender and the receiver connection, and most applications will effectively only use a very limited set by default if they go through one of the more high-level libraries. Also, when metadata is collected, the code mostly takes temporary references on objects like PIDs, namespaces etc. Which operation would you consider particularly expensive? Thanks again, Daniel