Re: KTH support for openldap

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Booker Bense wrote:
> - If you put an #ifndef HAVE_KTH_KERBEROS around the whole thing
> it works just fine as the des.h in KTH has the crypt prototype.

UNIX crypt(3) (for passwd(5)) in des.h?

Since there is no code that depends on both UNIX crypt(3) and Kerberos,
the clash can easily be worked around.  We can modify the headers such
that <crypt.h> is included for the ldappasswd/-llutil and excluded in
codes dependent on kerberos headers.

Basically, I'm thinking of creating a new header <ac/crypt.h>
that would do The Right Thing (TM) for crypt(3) callers.  Other
sources, including Kerberos dependent codes, would include
<ac/unistd.h> and not have to fear that an incompatible <crypt.h>
was included.

I committed a change a long these lines...

> > We could easily add AC_CHECK_HEADERS( krb-archaelogoy.h ) and
> > use the result to set HAVE_KTH_KERBEROS if there are no
> > better flags (such as Kth specific #define).
> - I'll ask the authors if there's a better solution.

I used krb-archaelogy.h based Kth detection for now.  We
can update easily enough.

> - Yes, In my testing I just ran configure --with-kerberos=k4.
> The autodecting didn't work, but that may be because my environment
> is so wierd. I have 5 different versions of "kerberos" in various
> directories on my machine.

In auto mode, it goes after k5 first.   I'll add a kth option.
I assume k5 kth k4 is an appropriate auto detection order.

> - I guess I wasn't too clear. I meant to ask whether you wanted
> me to email you patches and in what format. The changes are pretty
> trivial. I've attached cvs diff -u patches to ud/auth.c and
> ac/unistd.h to this message. They have a bogus #define
> HAVE_KTH_KERBEROS in them.

In general,  cvs diff -u patches against current -devel (HEAD branch)
are preferred.  It's best to submit them using our Issue Tracking
System after discussion on this list.  Patches sent directly to me
will be returned.

In this case, as I already committed changes, a formal ITS is not
necessary.  Please test.

> -P.S. The more I think about it, it seems to me that if you had
> all kerberos versions use krb_get_pw_in_tkt then you could use
> the same source for all and dump the HAVE_AFS flag.  That flag
> is only used in one place, ud/auth.c. It's a hack to allow you
> to get a ticket from an AFS K4 server with an unaltered MIT K4
> library. I guess it was useful at Umich, but it seems very odd
> to me that you would have AFS and not a K4 library that handles
> this for you. SOP in the afs world is that you use MIT K4 libraries
> with a hacked in string_to_key, so you don't have to put this code
> in every app that wants to get a tgt.

Comments from AFS users?