[OpenAFS-devel] [LKML] Re: In-kernel Authentication Tokens (PAGs)

[Jeffrey Hutzelman]

On Monday, July 12, 2004 22:36:12 -0400 Garrett Wollman 
<wollman@khavrinen.lcs.mit.edu> 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