[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