On Monday, July 12, 2004 22:36:12 -0400 Garrett Wollman <[EMAIL PROTECTED]> wrote:
a) Given a subject process, find the appropriate authentication context.
b) Place a given subject process in a newly-initialized authentication context, such that it will be inherited by all of the subject's children.
...and for efficiency it would also like:
c) When an authentication context is no longer "in use" (FSVO), release the resources allocated to it.
Well, we don't actually do that, since PAG's themselves have no resources (they're just a number).
(I am ignoring the evil "(d) Place my parent process in a new context" option for the moment as I think we all agree that it must go.)
Yup.
OpenAFS does not care about the inverse operation of (a): given an authentication context, find all of the subject processes which belong thereto.
Nope. But in the current model, we do care about being able to tell whether a given context (PAG) is in use by any processes. I'd settle for notification when the last ref goes away.
Unfortunately, the term PAG seems to be used interchangeably for two distinct concepts: one is the authentication context itself, and the other is the integer nonce which is used by historical AFS implementations to name authentication contexts for the purposes of (a). This is true in both the code and the documentation, not to mention conversations on this mailing-list.
True.
The former is essential to the function of AFS. The latter is an artifact of the current OpenAFS (and Transarc AFS) implementations, and is clearly dispensable on those operating systems which provide a better native mechanism
Sure. But "remembers a key for me" is not a better native mechanism. It is a solution to a completely different problem.
(as AIX appears to, by my reading of the code).
I know that implementing (a), (b), and (c) is trivial using the TrustedBSD framework. The Linux "keyring" notion that has been discussed seems well able to provide (a) and (c) but I'm not so sure that it provides the semantics AFS demands for (b). (AIUI, the reason (b) is so restricted is to prevent privilege escalation that would otherwise be possible if a process were permitted to join another authentication context by renouncing its credentials.)
Actually, I suspect we'd be willing to allow less strict semantics for (b) than you describe. But I'll have to think about that for a bit, and I'm late for dinner.
-- Jeff
_______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
