I wrote:
> The answer is "no, it doesn't work":
> $ psql -l
> psql: GSSAPI continuation error: Invalid token was supplied
> GSSAPI continuation error: No error
> $
> This surprises me; I would have thought the protocol was fairly
> orthogonal to the auth method. We should look into it and see
> if there's an easy fix or not. I have no time to poke further
> right now, though.
The problem seems to be that AuthenticationGSSContinue messages carry
a variable-length payload, and the V2 protocol doesn't really cope with
that because it doesn't have a message length word. In the existing
libpq code, the V2 path ends up computing "llen" as zero because it's
used a phonied-up value of msgLength. So it doesn't pass any of the
contained data to GSS, and the error message is maybe not so surprising.
So there seem to be three possible responses:
1. If the GSSContinue payload is self-identifying about its length,
qwe could teach fe-connect.c how to determine that. That doesn't look
real promising; I see this in strace output:
recvfrom(4,
"R\0\0\0\10`\201\226\6\t*\206H\206\367\22\1\2\2\2\0o\201\2060\201\203\240\3\2\1\5\241\3\2\1\17\242w0u\240\3\2\1\20\242n\4l|&\375a?\252}\25\241\344x\366aioX\17+I\356\215\265\252\260\353g|S\235\241
2F\25\237\254\365EZ\376Ws\20\23\tF#\37\362);/G\362\242\225D\366z\320\340\225\213p3_;\235\276\363\262o\30\6\t\225\3\351\365+\3546L#\4\243\31e\206z\0065~\345\203\200\201A\210\345\366\346\344\n<\275\26r",
16384,0, NULL, NULL) = 158
It looks like all encrypted data after the authentication type code, but
maybe there's something there that I'm not aware of.
2. We could retroactively redefine the contents of
AuthenticationGSSContinue as carrying a length word after the
authentication type code, but only in V2 protocol (so as not to break
existing working cases). This is pretty ugly but certainly possible.
3. We could decide not to support GSS in V2 protocol. If so, I'd want
to make the backend throw an error in this case, rather than proceeding
to send a message that we know can't be interpreted successfully.
Thoughts?
regards, tom lane
