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: