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

[Garrett Wollman]

<<On Mon, 12 Jul 2004 21:36:29 -0400, Jeffrey Hutzelman <jhutz@cmu.edu> said:

> A PAG is not a set of credentials; it is a set of _processes_ which share 
> the same authentication context.

Would you accept the following rephrasing:

	A PAG is an authentication context shared by a tree of processes.

To the best of my understanding, that is how PAGs are used in the
OpenAFS code.  I think this is an important point, because your
definition implies certain properties of a PAG that are not necessary
for what OpenAFS wants.  OpenAFS is only interested in the following
operations:

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.

(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.)

OpenAFS does not care about the inverse operation of (a): given an
authentication context, find all of the subject processes which belong
thereto.  OpenAFS does not permit any variations on (b).

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.

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 (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.)

-GAWollman