open-sshd uses non-default Kerberos cred cache breaking Kerberized NFS

Herbert emailed with a problem using the kerberized NFS client
in FreeBSD. He has been able to isolate the problem to the fact
that the sshd he uses (from open-sshd in ports) uses a non-default
tgt credentials cache.

The problem is that the gssd sets KRB5CCNAME to /tmp/krb5cc_<N>,
where <N> is the effective uid of the process doing the NFS RPC,
so that it can do an init_sec_context() GSSAPI call to get the
GSSAPI token. This fails if the tgt is in a credentials cache
file under a different name.

Here's the code snippet from gssd.c:
	snprintf(ccname, sizeof(ccname), "FILE:/tmp/krb5cc_%d",
	    (int) argp->uid);
	setenv("KRB5CCNAME", ccname, TRUE);

I can't think of any way to fix this, since the gssd runs as
effective uid==0 and needs to access the credentials cache for
other users.

Can anyone conversant with Kerberos suggest a fix?

Or does anyone know if there is an easy way to tell open-sshd
to use the default credential cache file name?

If not, all I can think of is to document this in gssd.8.

Thanks in advance for any help with this, rick

[Herbert Poeckl wrote in an email to me, copied with his permission]
> Hi Rick,
> 
> On 09/20/2012 11:45 PM, Rick Macklem wrote:
> >>> Ok, after the mount, if you log in as a non-root user, kinit as
> >>> that
> >>> user to get a tgt, then try and access the mount point... "what
> >>> happens"?
> >>
> >> And then the request for root_at_IST.INTRA happens.
> >>
> > If you can capture packets from the mount until this happens and
> > email
> > it to me, hopefully I can spot when this happens. For example, try
> > something like:
> > # tcpdump -s 0 -w file.pcap host srv.ist.intra
> > - then in another window
> > # mount -t nfs -o nfsv4,gssname=host,sec=krb5 srv.ist.intra:/<path?>
> > /mnt
> > #
> > - then in a window logged into a non-root user that has kinit'd
> > % ls /mnt
> > - and whatever else it takes to cause it to access root_at_IST.INTRA,
> > which
> >   shouldn't happen. (It should use the non-root user's principal or
> >   the
> >   host/soy.ist.intra_at_IST.INTRA one.)
> >
> > My guess is that some recent change has confused it so it tries to
> > use a
> > credential for uid 0.
> 
> I did some more testing.
> 
> This is what I found out:
> 
> If the environment variable KRB5CCNAME for the user is not set, or is
> set to FILE:/tmp/krb5cc_20001 (user with uidnumber 20001) then
> everything works as expected!
> 
> If the environment variable is set to something different, which
> happens
> when the user logs in with SSH, like FILE:/tmp/krb5cc_20001_HNYQhqGftu
> then I get the problem as described (request for root_at_IST.INTRA).
> 
> Herbert