Solaris kNFS and credentials caches

[Ken Hornstein]

>I have a Solaris 8 SEAM KDC, and am serving NFS with sec=krb5i on 
>Solaris 8.  I have clients running Solaris 8 (SEAM 1.0.1) and 9's included 
>SEAM, which can only access krb5i protected exports if the current 
>process' credentials uses the default cache name.   
>
>So basically, when I have credentials stored in the default location 
>(/tmp/krb5cc_UID), I can access these protected exports.  If they live 
>in say, /tmp/krb5cc_UIDNNN, I get permission denied upon trying to 
>access said exports.

I heard about this one from the guys at Sun.

The issue here is that there's a helper daemon (gsscred, I believe) which
gets Kerberos credentials for a user and passes them back to the kernel.
But they ran into two problems:

- The kernel (AFAIK) only identifies people by a Unix userid.
- You don't have a way of knowing which processes are using which credentials
  (the information isn't passed up the kernel to the right place).

So they choose to make it so that gsscred would look for Kerberos credentials
using the "standard" UID-based naming system.  Which I guess, from their
perspective, was a easy-to-implement solution, and I personally can't fault
them for that one.

My suggestion to the guys at Sun at the time was to provide a kernel/gsscred
interface to pass the necessary Kerberos bits associated with a process/
process group/POSIX session to the gsscred daemon, but that gets into a
bunch of hairy stuff (and it makes you realize that AFS PAGs aren't such
a bad idea after all).

Anyway, as I see it, right now you're stuck.  Probably your best solution
would be to modify your application servers so that instead of writing
out credentials to /tmp/krb5cc_p%d files, they merge them into each credential
cache based on the standard UID-naming scheme.  I admit that's hardly ideal
and will be a bit of code to write, but I'm not sure what else to do.
Or you can bug Sun and see what they say.

--Ken