To: Linus Torvalds <torvalds@transmeta.com>
cc: Garance A Drosihn <drosih@rpi.edu>, Jan Harkes <jaharkes@cs.cmu.edu>,
       David Howells <dhowells@redhat.com>, 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: <Pine.LNX.4.44.0305141749490.28007-100000@home.transmeta.com> 
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 <dhowells@warthog.cambridge.redhat.com>
Sender: linux-kernel-owner@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/