Обсуждение: GSSAPI and V2 protocol
Is it possible to authenticate using GSSAPI over the V2 protocol? Is there any documentation on the message formats for V2? Kris Jurka
On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: > > Is it possible to authenticate using GSSAPI over the V2 protocol? Is > there any documentation on the message formats for V2? Honestly - don't know :-) Never looked at that part. I mean, the V2 protocol is *really* old by now, isn't it? Do you actually need it for something? //Magnus
On Tue, 5 Feb 2008, Magnus Hagander wrote: > On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: >> >> Is it possible to authenticate using GSSAPI over the V2 protocol? Is >> there any documentation on the message formats for V2? > > Honestly - don't know :-) Never looked at that part. I mean, the V2 > protocol is *really* old by now, isn't it? Do you actually need it for > something? > The JDBC driver exposes an option to connect via either protocol version. I was looking at adding GSSAPI support and it seemed orthogonal to the protocol version used, but I couldn't get it working under V2. People still use the V2 protocol to connect because it uses string interpolation for ? in prepared statements while V3 passes them out of line. So for apps that do things like "SELECT timestamp ? " that will only work under V2. Kris Jurka
Kris Jurka wrote: > > > On Tue, 5 Feb 2008, Magnus Hagander wrote: > >> On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote: >>> >>> Is it possible to authenticate using GSSAPI over the V2 protocol? Is >>> there any documentation on the message formats for V2? >> >> Honestly - don't know :-) Never looked at that part. I mean, the V2 >> protocol is *really* old by now, isn't it? Do you actually need it for >> something? >> > > The JDBC driver exposes an option to connect via either protocol > version. I was looking at adding GSSAPI support and it seemed orthogonal > to the protocol version used, but I couldn't get it working under V2. > People still use the V2 protocol to connect because it uses string > interpolation for ? in prepared statements while V3 passes them out of > line. So for apps that do things like "SELECT timestamp ? " that will > only work under V2. Ok. I see the reason, but I can't help you further. Requires a deeper dig in the code, I guess. Does this mean you have GSSAPI auth working for protocol v3? :-) //Magnus
On Tue, 5 Feb 2008, Magnus Hagander wrote: > Does this mean you have GSSAPI auth working for protocol v3? :-) > Yes, but since I'm not terribly familiar with GSSAPI or JAAS, I'm not sure what configuration options need to get exposed to the user. http://archives.postgresql.org/pgsql-jdbc/2008-01/threads.php#00144 Kris Jurka
Kris Jurka wrote: > > > On Tue, 5 Feb 2008, Magnus Hagander wrote: > >> Does this mean you have GSSAPI auth working for protocol v3? :-) >> > > Yes, but since I'm not terribly familiar with GSSAPI or JAAS, I'm not > sure what configuration options need to get exposed to the user. > > http://archives.postgresql.org/pgsql-jdbc/2008-01/threads.php#00144 Hmm. I think most of that is a Java issue, which I know next to nothing about. But you would need to be able to control at least as much as libpq is - which means you need to be able to control the service name, and that's about it. Not sure how it works on windows - for libpq on windows, you can choose if you want MIT kerberos or if you want the SSPI kerberos in Windows, dunno if that applies to the java stuff. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Jan 29, 2008 at 03:34:19AM -0500, Kris Jurka wrote:
>> Is it possible to authenticate using GSSAPI over the V2 protocol? Is
>> there any documentation on the message formats for V2?
> Honestly - don't know :-) Never looked at that part.
I tried it --- it's easy to hack libpq so that it does V2 instead of V3:
$ diff -c fe-connect.c~ fe-connect.c
*** fe-connect.c~ Mon Jan 28 21:06:30 2008
--- fe-connect.c Tue Feb 5 19:35:34 2008
***************
*** 855,861 **** conn->addrlist = addrs; conn->addr_cur = addrs; conn->addrlist_family =
hint.ai_family;
! conn->pversion = PG_PROTOCOL(3, 0); conn->status = CONNECTION_NEEDED; /*
--- 855,861 ---- conn->addrlist = addrs; conn->addr_cur = addrs; conn->addrlist_family =
hint.ai_family;
! conn->pversion = PG_PROTOCOL(2, 0); conn->status = CONNECTION_NEEDED; /*
$
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.
regards, tom lane
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
On Tue, 5 Feb 2008, Tom Lane wrote: > 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. > > 1. If the GSSContinue payload is self-identifying about its length, > qwe could teach fe-connect.c how to determine that. The GSS data is supposed to be opaque to the caller, so this doesn't seem likely or a good idea. > 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? Kris Jurka
On Wed, Feb 06, 2008 at 02:57:39AM -0500, Kris Jurka wrote: > > > On Tue, 5 Feb 2008, Tom Lane wrote: > > >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. > > > >1. If the GSSContinue payload is self-identifying about its length, > >qwe could teach fe-connect.c how to determine that. > > The GSS data is supposed to be opaque to the caller, so this doesn't > seem likely or a good idea. Yeah, agreed, that seems like a very fragile idea. > >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. //Magnus
Magnus Hagander <magnus@hagander.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.
regards, tom lane
Tom Lane wrote: > Magnus Hagander <magnus@hagander.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
Magnus Hagander <magnus@hagander.net> writes:
> Tom Lane wrote:
>> 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.
This problem applies to SSPI too, correct?
regards, tom lane
On Thu, Feb 07, 2008 at 06:58:25PM -0500, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > Tom Lane wrote: > >> 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. > > This problem applies to SSPI too, correct? Yeah, they work the same way. //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> On Thu, Feb 07, 2008 at 06:58:25PM -0500, Tom Lane wrote:
>> This problem applies to SSPI too, correct?
> Yeah, they work the same way.
OK, I've fixed the server side to complain before any unparsable data
is sent or received. But this happens after AuthenticationGSS or
AuthenticationSSPI is sent, so the frontend could choose to handle
the case itself if it prefers.
regards, tom lane