Re: Preliminary GSSAPI Patches

On Tue, Jun 19, 2007 at 06:19:37PM -0700, Henry B. Hotz wrote:
> 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 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.

I've got a bit more cleanup to do, but I'm almost there.

Much of it is just cleanup. I've changed the structs arond to be more in
line with the other code around it, and such. Refacored some of the code to
cut down duplicate codes. Added some stuff to make it work on windows
(still just with MIT kerberos and not native though). Fixed two (I think it
was) small memory leaks.

Protocol-wise, it no longer piggybacks int eh AuthenticationOk message -
instead we send an extra continue message followed right away by an
AuthenticationOk one.

Oh, and I've added autoconf. Not complete yet, but getting there :-)

I'll post the updated patch shortly :-)

> >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?

Not really ;-) I did check the code, and it certaily wasn't right the way
it was. I added some manual packet injection, and it ended up in the wrong
place. It looks right now, and I'll have to test that eventually (my test
packets end up in the right place now). But what I have now *seems* right.

> >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.

The client side was much more complete, yes :) And with my other chanegs to
the protocol, it actually gets more than one packet.

As for the server-side fix, it was just moving a couple of lines of code
inside the loop...

//Magnus