Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S264009AbTEONWv (ORCPT ); Thu, 15 May 2003 09:22:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263997AbTEONWv (ORCPT ); Thu, 15 May 2003 09:22:51 -0400 Received: from pub237.cambridge.redhat.com ([213.86.99.237]:32214 "EHLO warthog.warthog") by vger.kernel.org with ESMTP id S263936AbTEONWp (ORCPT ); Thu, 15 May 2003 09:22:45 -0400 To: Linus Torvalds cc: Garance A Drosihn , Jan Harkes , David Howells , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, openafs-devel@openafs.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 14:35:15 +0100 Message-ID: <6445.1053005715@warthog.warthog> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5836 Lines: 132 > > For any process where pag != 0, that process will share > > tokens with all other processes that have the exact same > > pag value as it has. This is true even if the different > > processes are tied to different user ids. > > Yeah, and the thing I think it _totally_ and utterly broken is that there > can be only one of these per process. > > I don't see where the 1:1 idea comes from, except from a bad > implementation. Where's this 1:1 come from? PAGs aren't 1:1 with processes, nor are they 1:1 with users. I've tried to implement them as I understand the design information I could find (which specified that any process could belong to a single PAG). From the comments that have been made, it seems that each user needs some sort of fallback token set for any process that doesn't have a PAG. > > There is absolutely no connection between userids and PAG's, > > the same way that there is no connection between userids and > > process-numbers. (Roughly speaking:) The 10th person to log > > in will get the 10th pag, no matter what userid they happen > > to log in as. > > And this is also again nothing but the result of a bad implementation. That's the design. Since AFS uses the PAG as part of the lookup key, it seemed reasonable to make a more formal association between the credential ring and the PAG in the kernel (especially as I needed someway of (a) generating a unique PAG, and (b) performing garbage collection on PAGs). > From a system maintenance issue, this is a nightmare. It makes joining a > group nigh impossible, since now the joiner (login or something) has to > keep track of what pag's it has used for previous logins. Which is fine as > long as you have _one_ login authority, but it's a total disaster to > require that kind of centralization. Adding credentials to groups seems to be tricky (if not superfluous - surely that's what ACLs are for). Who should add creds to groups? And assuming like kerberos is used, wouldn't the lifetime a credential attached to a group then be dependent in some way on the authorisation granted to the user who requested the group cred in the first place? It's also not a total disaster to have a central login authority (assuming I'm understanding your objection correctly). It's necessary for many reasons (including distributed filesystems), and is supported any many ways: kerberos, YP/NIS, M$ SMB, LDAP. It seems to me that what is required is a ring of tokens, each of which says: When accessing data in domain "A" using protocol "B", present myself as user "C" using credential "D" from authority "E". Then the servers in domain "A" say: User "C" is trying to read datum "F". I validated his/her presented credential against "E". Datum "F" may be accessed in certain ways by users "G" and "H" and the members of groups "I", "J" and "K". Aha! User "C" is in group "J", and members of "J" are allowed to read "F", write "F" and turn "F" into a can of spam. Okay, "C" is allowed to read it. But what do you do for a group credential? When accessing data in domain "A" using protocol "B", present myself as group "J" using credential "D" from authority "E". This isn't good - if group management is handled on the client, the server then has to be able to trust the client absolutely. You could add a credential to a group so that users accessing files in a particular domain do so as a special user (use the user "engineering" for example when accessing files in devel.redhat.com), but I suspect that sort of thing isn't really what you want. I think that what you want there is ACLs. Furthermore, I think a process's gid and groups[] are something of a dead herring in this respect. They are a primitive ACL-like mechanism that's fine for UNIX local filesystems (in which case the kernel acts as its own authority), but don't necessarily map to network filesystems (though they are used by NFS/RPC doing AUTH_UNIX). Furthermore, PAGs and your group rings ought to self-destruct when nobody is referring to them as they consume kernel resources. > Right now the limited PAG namespace as implemented by the current patch > means that a PAG ID number _has_ to be throw-away: the namespace is too > small to give users permanent PAG ID's. PAG IDs are designed to be throw-away. > That's fine per se: you can always create a mapping layer in some > outside-of-the-kernel way (ie a database of "user -> currently used PAG > space"), but it's so much easier - I think - to just make the name space big > enough that you can have a trivial static mapping "user -> permanent PAG > ID". You'd still need the outside-of-the-kernel database or whatever. Otherwise, what would the ID numbers mean? After all, how do you know which UID number corresponds to your account? The ability to join PAGs is mostly unnecessary, it's just that it seems the facility is useful for a few specialised purposes (NFS->AFS translator being the primary one IIRC), and could possibly be dispensed with. It may be worth doing three things to my patch: (1) Discard setpag(pag_t). (2) Make pag_t either unsigned long (though this may cause problems when running a 32-bit program on a 64-bit arch) or unsigned long long and returned through a dereferenced pointer. (3) Add a default PAG to every struct user and add a syscall to attach the process to this PAG instead of what it is currently using. Though I don't expect you'll agree to that. It's not that I'm particularly attached to PAGs, it's just that they're a simple way of doing what I require. 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/