Re: GSSAPI and V2 protocol

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>, Kris Jurka <books(at)ejurka(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: GSSAPI and V2 protocol
Date: 2008-02-06 03:55:09
Message-ID: 1569.1202270109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2008-02-06 04:28:52 Re: Re: [COMMITTERS] pgsql: configure tag'd 8.3.0 and built witih autoconf 2.59
Previous Message Decibel! 2008-02-06 01:39:48 Re: configurability of OOM killer