Re: [HACKERS] GSSAPI and V2 protocol
On Thu, Feb 07, 2008 at 06:58:25PM -0500, Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GSSAPI and V2 protocol
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GSSAPI and V2 protocol
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GSSAPI and V2 protocol
Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GSSAPI and V2 protocol
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GSSAPI and V2 protocol
Magnus Hagander [EMAIL PROTECTED] 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.cTue 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GSSAPI and V2 protocol
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
