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

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


On Monday, July 12, 2004 19:02:46 -0400 John Bucy 
<bucy-openafs-devel@gloop.org> wrote:

>
> Here's Kyle Moffett's reply to my ping about the semantics of the
> proposed new PAG facility for Linux.  Here's a pointer to a fairly
> recent description of the whole thing:

So, keyrings are pretty and all, but please stop calling them PAG's, 
because that is not what they are.  Filesystems like AFS and NFSv4 don't 
need keyrings; they need PAG's.

PAG stands for "Process Authentication Group".

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

For an encrypted local-disk filesystem, maybe a key is all you need.

For complex network filesystem implementations like OpenAFS, Arla, and 
NFSV4, authentication context means much more.  For example, it may (does) 
include a set of open authenticated connections to fileservers.  These are 
shared between processes in the same PAG -- we don't open a new connection 
to the fileserver for every process that wants to read a file.  It also 
includes cached access control data -- the cache manager is responsible for 
ensuring that it gives cached data only to processes which are authorized 
by the fileserver to have it.  To do this efficiently, it must cache 
information about what rights are granted on a given file to processes in a 
given authentication context.


But wait; it gets worse.  In current NFSv4 implementations, part of the 
process of establishing an authenticated connection (in particular, the 
part that needs the user's credentials) happens in user mode.  This process 
needs access to the right credentials.  Now, I'm not active in NFSv4 
development, so I can't say which model they're using, but there are 
basically two ways to handle this -- either all context establishment is 
handled by a single, system-wide process, or there is a separate process 
for each authentication context.  In the former case, the NFSv4 code in the 
kernel needs to know when it can share connections between processes, and 
which set of credentials to tell the helper to use for any given new 
connection.  In the latter case, it needs to know which helper to associate 
with what process and, again, which processes can share connections.

But wait; it gets worse.  In Arla, all the hard parts are actually handled 
in a single user-mode process (arlad).  This process maintains connections 
to fileservers, manages the cache, moves data around between them.  Of 
course, to do this, it must maintain multiple authentication contexts, 
using the correct connection(s) to perform operations on behalf of each 
process, and ensuring that access controls are enforced.  In other words, 
it has to do everything that OpenAFS and NFSv4 do.  And, to do this, it 
must know which processes have the same authentication context; that is, 
which processes are in the same PAG.


-- Jeff