Message-ID: <CA+55aFyngC1GN7Nr7bfNtDw4ub_GB59Tz0u0L8PtwKX1Q2zuYw@mail.gmail.com>
Date:	Thu, 23 Apr 2015 14:05:42 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Jiri Kosina <jkosina@...e.cz>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Mack <daniel@...que.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>
Subject: Re: Sharing credentials in general (Re: [GIT PULL] kdbus for 4.1-rc1)

On Thu, Apr 23, 2015 at 12:41 PM, Andy Lutomirski <luto@...capital.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists