[OpenAFS] Linux kernel 2.6 & AFS

Jim Rees rees@umich.edu
Fri, 27 Feb 2004 11:48:26 -0500


  How you actually push the authentication credentials into the kernel
  is a separate problem, and I'm not sure if there *IS* a generic mechanism
  for this (nor am I convinced there should or can be).

Let me put in a plug here for our NFSv4 gssd.  The general idea is that you
don't want to put all of kerberos, or any other security flavor, in the
kernel.  And even if you could, you would still want to share creds between
user and kernel space.

So what we do instead is keep the creds in user space, using whatever
storage space is native to the mechanism.  Then we have a user space daemon,
the gssd.  When a kernel thread needs some cred on behalf of a user, it
makes an upcall to the gssd, which passes a cred, or part of it, down to the
kernel, which then caches it for future use.  The bulk data encryption is
then done in the kernel without any upcall.  Note that creds are passed down
in response to a kernel request, rather than being stuffed down at the time
they are acquired.

We've been an afs shop for years, much longer than we've been an nfs shop,
so we tried to keep this generic.  It can't be directly used for afs right
now, but that's just because no one has defined a k4 mechanism for gss (but
gssklog would be a good place to start).

It's probably too heavy weight for afs now, but if afs were to move towards
k5, I think it would make sense to use our gssd.  One advantage is that it
will soon be part of most linux distros and FreeBSD, because of NFSv4.

We need to write more documentation, but you will find some info here:

http://www.citi.umich.edu/projects/nfsv4/