Such timing!

I just spent most of yesterday stepping though the gssapi sample app's in Java 1.4 with someone here at work. Was thinking I needed to get back to the JDBC client and do what I promised. Also finished filtering the PG lists for stuff just before seeing this email.

On Jun 19, 2007, at 6:04 AM, Magnus Hagander wrote:

On Sun, May 20, 2007 at 01:28:40AM -0700, Henry B. Hotz wrote:
I finally got to testing that updated patch.  It's fine per-se, but
was missing the updated README.GSSAPI file.  Herewith fixed.

I've been reviewing and updating this patch, for a while now.I've changed quite a bit around, and I have it working fine, but I have one question.

Be curious to see what you've done, but if you're actively changing things I'll let them settle.

Is there a way to provoke GSSAPI into sending multiple packets in the
authentication? It doesn't seem to do that for me, and ISTM that the code
as it stands is broken in that case - but I'd like to verify it.

Remember wondering about that myself. For SASL if you turn on all the options you get an extra round trip. Not for GSSAPI/Krb5, which is pretty efficient in that respect. The loop logic for SASL is just different enough I can imagine messing up, but I would have thought it would have made me get the logic right.

The only thing I can think of is to use a different GSSAPI mechanism. That opens an interesting can of worms that has nothing to do with Postgresql. First of all that means you need to use a GSSAPI implementation that supports multiple mechanisms (which precludes Java for now). That in turn means either Sun, or MIT 1.6+, or Heimdal 0.8+. Second, you need another mechanism to install. That means the commercial Entrust SPKM mechanism on Sun, or the UMICH SPKM mechanism, or some SPNEGO mechanism.

Love says there are problems with the SPKM RFC and the UMICH implementation won't interoperate with other implementations as a result (but it works with itself). I also know he's been experimenting with other mechanisms. Looking at the latest Heimdal snapshot I have, it seems to have both SPNEGO and NTLM mechanism code in it.

A configuration that used SPNEGO to negotiate Kerberos 5 ought to take two round trips, at least. Feel like trying it?

I never tested my patches against a Heimdal gssapi library. My bad. If you try the patches against Heimdal GSSAPI/SPNEGO/Krb5 that ought to be a really good test case. It would be a good server case to try with a native Windows client as well.

Basically, pg_GSS_recvauth() is supposed to loop and read all "continuing exchange packets", right? But the reading of packets from the network sits *outside* the loop. So it basically just loops over and over on the same data, which ISTM is wrong. It does send a proper ask-for-continue message to the frontend inside the loop, but I can't figure out how it's supposed
to read the response.

I remember having to stand on my head to get it (apparently) right on the client side. I also remember the server side was a lot simpler, but you're saying I may have oversimplified? I can't answer the question about the server side without reviewing the code.

It looks like the fix should be as simple as moving the packet reading into
the loop, but again I'd like a way to test it :)

Well, probably, but that doesn't sound that simple to me (assuming I really didn't do that to begin with).


The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to