Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264103AbTEOQ2o (ORCPT ); Thu, 15 May 2003 12:28:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264110AbTEOQ2o (ORCPT ); Thu, 15 May 2003 12:28:44 -0400 Received: from pub237.cambridge.redhat.com ([213.86.99.237]:61660 "EHLO warthog.warthog") by vger.kernel.org with ESMTP id S264103AbTEOQ2k (ORCPT ); Thu, 15 May 2003 12:28:40 -0400 To: Linus Torvalds cc: Dean Anderson , Trond Myklebust , Garance A Drosihn , Jan Harkes , David Howells , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [OpenAFS-devel] Re: [PATCH] PAG support, try #2 In-Reply-To: User-Agent: EMH/1.14.1 SEMI/1.14.4 (Hosorogi) FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.4 Emacs/21.2 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: text/plain; charset=US-ASCII Date: Thu, 15 May 2003 17:41:01 +0100 Message-ID: <7736.1053016861@warthog.warthog> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2845 Lines: 71 > > Pardon me if I'm wrong, but doesn't the PAG already allow for multiple > > credentials? > > Yes, but the patch did not allow for > > - partial sharing (keys are bound to _one_ PAG, and one PAG only) > > This makes "revoke" pretty much useless, since you have a damn hard > time finding all the keys, since you have to copy them around instead > of sharing one instance. Okay, so separate PAG IDs and credentials. Have a separate credential cache to which the PAG ID is but one of the keys, then share entries that have a common (remote-user-ID,fsname,domain) key. > It also makes grouping very hard. Grouping is superfluous and not trivial at any time. Use ACLs. > - the name space is so limited that you _have_ to consider the PAG ID's > temporary, which means that you have to add a whole new layer of > maintenance in user space. PAG IDs _are_ ephemeral. > Neither of these are apparently problems in the AFS world, because there > is only one entity that gives out keys, so that one entity can keep track > of every key ever allocated. That's not exactly so (see next comment). > But look at the big picture. What happens when you have multiple sources > of keys that have nothing to do with each other. Like AFS, you mean? Each AFS cell (or cell group) may contain an independent kerberos server that dispenses keys that are nothing to do with the kerberos tickets granted by another cell. For instance, the openafs.org cell my grant me a ticket for accessing there, but that wouldn't be any use for redhat.com or cambridge.redhat.com cells. Whereas the redhat kerberos server might grant me a ticket that'd permit me to access either redhat cell. > How do you maintain sanity in that kind of world, when the numbers don't > have any meaning, and one of the key maintainers doing a "join" operation > will throw away all the work that the other key maintainers did. Assuming there is a join operation. I think setpag() should go, leaving only newpag(). > > Linus seems to be arguing for multiple PAGs, like multiple > > GIDs. But I think that functionality is really there, inside the PAG. > > No it isn't. You can't do independent joins, since as it is, the code has > an "all or nothing" approach. Independent joins aren't necessarily good either. They add lots of complexity and consume lots of kernel resources. > Again, this works in a single-use environment, where there is central > control. It _sucks_ if you want to have a generic "bunch of keys" model. I've tried to make my PAG patch support a multi-use environment. David - 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/