Re: Patch to add Heimdal kerberos support - Mailing list pgsql-patches

From Bill Studenmund
Subject Re: Patch to add Heimdal kerberos support
Date
Msg-id Pine.NEB.4.33.0111131815360.27966-100000@vespasia.home-net.internetconnect.net
Whole thread Raw
In response to Re: Patch to add Heimdal kerberos support  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
On Tue, 13 Nov 2001, Tom Lane wrote:

> Bill Studenmund <wrstuden@netbsd.org> writes:
> > I'm not aware of something which says "Heimdal" or "MIT". Yes, I can
> > personally look at the libraries, and if I see libroken and libasn1, then
> > chances are it's heimdal, and if I see libk5crypto (I think that's the
> > one), chances are it's MIT. But I'd like the configure script to be more
> > robust - how do we tell if we have a broken install of either type?
>
> Peter Eisentraut is our local autoconf guru, and perhaps will be willing
> to help you out with this.  But my guess would be that we link with
> whichever libraries we see out there.  It's not our business to
> determine whether the Kerberos install is "broken".

Actually the current configure script makes it its business to tell if the
install is broken. :-) It tests that we can successfully link in a number
of symbols. For instance, "checking for com_err in -lcom_err", "checking
for krb5_encrypt in -lcrypto", "checking for krb5_encrypt in -lk5crypto",
and "checking for krb5_sendauth in -lkrb5".

These tests need to change depending on the flavor of kerberos. For
instance, under heimdal, krb5_encrypt is in libkrb5 and different libs
have to be linked in to make tests work (-lasn1 -lroken -lcrypto).

Looking at things, we might be able to look for the presence of the symbol
__heimdal_version to see if it's heimdal krb5:

> strings /usr/lib/libkrb5.so | grep -i heimdal
__heimdal_version
__heimdal_long_version
@(#)$Version: heimdal-0.3e (NetBSD) $
heimdal-0.3e

So that would work/could be made to work.

> I still wonder whether there isn't some documented API (common to both
> MIT and Heimdal) for extracting the client principal from a ticket.
> I mean, that's almost the entire reason for getting the ticket in the
> first place; you can hardly argue that this is not core functionality.
> I find it hard to believe that Heimdal hasn't duplicated the standard
> way of getting the principal from a ticket.  I can believe that we
> weren't *using* the standard way, however...

I'm checking, but I remember comments from Jason Thrope, a NetBSD
developer who did some of the initial porting to heimdal after it was
brought into NetBSD. I think he was working on getting gssapi to work with
heimdal. There were many complaints about how the MIT code was taking
liberties with reaching into library internals, and the principal name
(what we're getting at here) was one of them.

Remember how Heimdal developed. A lot of its work was done during the
encryption==munitions==noexport era. So heimdal was written to the RFCs
and other published specs. What we're seeing here is one example of where
the specs didn't cover everything. No one bothered to make a way
(routines) to get the name, as you could just reach in the packet and get
it. Just the standards didn't describe the names of the fields in the
ticket structure, MIT and KTH chose different names, and no one noticed
until code had been written for both.  :-|

From talking w/ Ken Hornstein (keeper of the kerberos FAQ), the APIs are
different at the moment. They are working to merge them, but they are
still different. And from PostgreSQL's point of view, divergent versions
have been shipped.

Take care,

Bill




pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: Patch to add Heimdal kerberos support
Next
From: Barry Lind
Date:
Subject: Re: [JDBC] absolute() error with jdbc7.1-1.2