OPenAFS and OpenSSH replacing kafs

[Sergio Gelato]

* Ben Lindstrom [2004-03-01 15:25:08 -0600]:
> If this is a real bug in the headers.  Then apple should be informed and
> they should correct the issue.

I'll see about filing a bug report. However, it's a minor problem (easy
to work around).

> This is a separate issue.  If you look at the Apple source code it is an
> optional patch for CCache API.  Unless Apple has stripped out the other
> forms of fetching creditionals.

There are actually two -D symbols, USE_CCAPI (which does little more
than replacing FILE: with API: in the credentials cache specification)
and USE_SECURITY_SESSION_API (which seems highly desirable, except on
a standard 10.3 install where sshd is always started by xinetd; in the
latter case xinetd already does the job and the corresponding code in
sshd is idempotent).

You are correct that the patches are optional, in the sense that sshd
will work without them. klist seems to default to API: rather than FILE:
when KRB5CCNAME doesn't specify the cache type, but that's a minor
annoyance (and a hint that Apple prefers the API: cache type).

... I think I've found a bug in session.c:
        if (s->authctxt->krb5_ticket_file)
                child_set_env(&env, &envsize, "KRB5CCNAME",
                    s->authctxt->krb5_ticket_file);
should probably prefix an explicit "FILE:" to the value of
s->authctxt->krb5_ticket_file. The GSSAPI code gets this right,
but the Kerberos password code doesn't. Should we fix this in
session.c or in auth-krb5.c ? 

On a different note, it seems that (as of version 71 of System.B)
getaddrinfo() is still broken, in that it does not fail with EAI_NONAME
when the AI_NUMERICHOST hint is given and the nodename is non-numeric.
I'm getting erroneous "Nasty PTR record" warnings as a result, and
I bet this also explains the tcp-wrappers configuration anomalies I've
observed on 10.3.
That's probably also worth a bug report to Apple. Will see if I can
come up with an improved test for BROKEN_GETADDRINFO in configure.ac, 
one that does more than just look at the library version number.

My top priority at the moment, though, is to sort out the MIC
verification failures I'm having. (They appear to correlate with the
client using Heimdal and the server MIT, so I'm smelling an
interoperability issue between the two. Probably an already-known one.)