On 8/3/06, Jeffrey Hutzelman <[EMAIL PROTECTED]> wrote:
On Wednesday, August 02, 2006 11:15:11 AM -0400 Derrick J Brashear
<[EMAIL PROTECTED]> wrote:
>>> That would be fine, I suspect, since NFS v4 would probably also use it.
>>> Kevin?
>>
>> I believe NFS4 is going to store its keys in the keyring directly,
>> rather than using a PAG. Would that be possible for AFS?
>
> Possibly, but not from day 1, which is how we are where we are now. It
> requires a flag day, which it would be nice to sequester to a major
> version release.
It seems this needs to be said again, so I'll say it.
It's not about storing keys. A PAG is not a place to store keys.
A PAG is a set of related processes.
We can't "store ... keys in the keyring directly, rather than using a PAG",
because we're not just "storing keys". Besides a set of keys, a PAG is
also associated with things like open connections to fileservers and cached
access rights. NFSv4 is going to have the same issues, at least if you
want the performance not to suck.
I agree that NFSv4 needs a pag-like feature. I have been living with
the assumption that the session keyring was the equivalent of a PAG --
which I think was David's original intention.
I'm running into issues now that might make a common PAG in the main
kernel desirable. The current rpcsecgss code keys contexts by UID
(among other things), which is not going to work.
I need to discuss this with Trond, who is not (physically) around right now...
K.C.
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
