Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031060AbbDWVFt (ORCPT ); Thu, 23 Apr 2015 17:05:49 -0400 Received: from mail-ig0-f177.google.com ([209.85.213.177]:33461 "EHLO mail-ig0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030940AbbDWVFn (ORCPT ); Thu, 23 Apr 2015 17:05:43 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 23 Apr 2015 14:05:42 -0700 X-Google-Sender-Auth: qEQqmBcxDKsAW8n-zhmCsHM-Thg Message-ID: Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1) From: Linus Torvalds To: Andy Lutomirski Cc: Greg Kroah-Hartman , 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 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: 3013 Lines: 63 On Thu, Apr 23, 2015 at 12:41 PM, Andy Lutomirski wrote: > > Objection 1: This thing is omnidirectional. I'm much less convinced > that it's okay for Angry Penguins or its associated ad network to find > out that the printer daemon is uid 38, that it's in cgroup > such-and-such, or that the printer daemon has the admin's permission > to feed the walruses. I think that is valid. It's one thing to send a request to somebody else and say "I am so-and-so". I think that when you connect to somebody else, that somebody else should be able to know who the requester is. But the service provider has no such onus on it. I agree. > Objection 2: There's a difference between the printer daemon knowing > that Angry Penguins has general permission to print and an explicit > assertion by Angry Penguins of its permission to print. Now, this I don't necessarily agree with. Simply because what you propose seems to require everybody to do something extra, and that adds complexity. When you open a file, you don't object to the fact that the VFS layer uses your privileges to check whether you can do that. It would be insane to say that the open system call should have an explicit argument saying that the vfs layer should take your privileges into account. (Which is not to say that that _can_ make sense - if you implement a server in user space, you might want an interface that says "open using these credentials". So such a model is not insane per se, but it *does* imply a lot more complexity, and there's a reason we don't do that. We *have* done user-level file servers in Linux, and the way it was done was that the open system call uses the current thread privileges implicitly, and the server that wants to do the odd and complex unusual thing has to explicitly modify its privileges around the open call!). So I think your second argument is weak. It doesn't actually match what we do normally in Unix. Yes, the mindset _can_ make sense, but it's different from normal behavior, and it's not at all clear that it is a good thing, because it introduces new issues and complexities along the lines of "how do I assert that I want you to check my credentials for *this* particular use (printing) but not for *that* particular use (passwd). IOW, your model seems to imply that you have to surround everything with yet another layer of enumeration of all the possible things you might want to do. And that seems just a bad idea to me. Why would system daemon permissions be so magically different from all the *native* permission handling we do? It's not like you open /etc/passwd with some special flag that says "I want to edit my password". No. You open /etc/passwd with the normal unix credentials. Linus -- 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/