Re: GSSAPI and V2 protocol

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

Tom Lane wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote:
>>> On Tue, 5 Feb 2008, Tom Lane wrote:
>>>> 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.
>>> I see no harm in doing this. What's there now can't work and the change
>>> is self contained. Is there any problem with the password message taking
>>> a "String" datatype instead of Byte[n] with a null byte?
>
>> I agree that this is probabliy the best way, if we can do it. But you do
>> raise a good point - the message that goes the other way can certainly contain
>> embedded NULLs.
>
> I hadn't thought about the response side of the problem, but yeah, it is
> equally broken. To fix that would have to mean that V2 has two
> different password message formats for GSS vs other cases, which I think
> is starting to exceed my threshold of ugliness --- we are now talking at
> least four places needing weird special cases for V2 vs V3 protocol, two
> each in the server and (each) client library. I also quite dislike the
> idea that a password message couldn't even be parsed without context
> knowledge about which auth method it was for.
>
> In retrospect it was a serious error to use the PasswordMessage format
> for GSS responses, but with 8.3 already out the door I'm afraid we
> are stuck with that decision.
>
> I vote we just decide that GSS isn't going to be supported on protocol
> V2, and put a suitable error message into the server for that. It
> doesn't seem to me that this combination is worth the amount of
> contortions it would require to support.

Agreed. The cost is rapidly becoming too high. But we certainly can't
change the protocol for the stuff that actually does work.

//Magnus

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-02-06 19:58:07 Re: Page-at-a-time Locking Considerations
Previous Message Simon Riggs 2008-02-06 19:49:34 Re: Why are we waiting?