Обсуждение: [ODBC] Connection failure with invalid connection option "gsslib" for 09.06.0410
[ODBC] Connection failure with invalid connection option "gsslib" for 09.06.0410
Hi all, When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I lagged behind one release!), I have noticed a failure when connecting to a Postgres instance on Windows: cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm --user test_odbc --pwd passw0rd --port 5444 stdout=Connecting odbc : DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd}; stderr=Traceback (most recent call last): File "check_odbc.py", line 111, in main check_odbc_connection(conn_str) File "check_odbc.py", line 15, in check_odbc_connection cnxn = pyodbc.connect(conn_str) Error: ('08001', '[08001] invalid connection option "gsslib"\n (101) (SQLDriverConnect)') check_odbc.py is a simple wrapper on top of pyodbc that attempts a connection to Postgres on Windows, making sure that the DNS defined is working correctly. There is nothing fancy in it. The difference between a failure and a success is only the update of the ODBC driver, so I'd like to think that it is its fault here ;) Looking at the code, I think that this diff in dlg_specific.c, coming from commit 3bad6c8e is at fault: @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char *attribute, const char *value) } [...] -void -getDSNdefaults(ConnInfo *ci) +static void +getCiDefaults(ConnInfo *ci) [...] - if (ci->gssauth_use_gssapi < 0) - ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI; [...] + ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI; This is a problem, because Postgres' libpq may not be compiled with GSS support, which is the case of my builds, and the existence of the connection parameter gsslib depends on if Postgres is compiled with GSS or not. I think also that this is the only problem, the other libpq parameter whose existence is defined based on compilation is krbsrvname, and odbc does not handle it. I have only seen this problem on Windows, because my Linux builds have GSS support, but I have no doubt that the problem could be seen there as well. Inoue-san, unfortunately I think that your commit is a fault here. Thanks, -- Michael
[ODBC] Re: Connection failure with invalid connection option "gsslib" for09.06.0410
Hi Michael, On 2017/08/21 10:01, Michael Paquier wrote: > Hi all, > > When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I > lagged behind one release!), I have noticed a failure when connecting > to a Postgres instance on Windows: > cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm > --user test_odbc --pwd passw0rd --port 5444 > stdout=Connecting odbc : > DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd}; > > stderr=Traceback (most recent call last): > File "check_odbc.py", line 111, in main > check_odbc_connection(conn_str) > File "check_odbc.py", line 15, in check_odbc_connection > cnxn = pyodbc.connect(conn_str) > Error: ('08001', '[08001] invalid connection option "gsslib"\n (101) > (SQLDriverConnect)') Unfortunately I can't reproduce it here with dns-less connections. What is in uninst_std_noimpact_srm? regards, Hiroshi Inoue > > check_odbc.py is a simple wrapper on top of pyodbc that attempts a > connection to Postgres on Windows, making sure that the DNS defined is > working correctly. There is nothing fancy in it. > > The difference between a failure and a success is only the update of > the ODBC driver, so I'd like to think that it is its fault here ;) > > Looking at the code, I think that this diff in dlg_specific.c, coming > from commit 3bad6c8e is at fault: > @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char > *attribute, const char *value) > } > [...] > -void > -getDSNdefaults(ConnInfo *ci) > +static void > +getCiDefaults(ConnInfo *ci) > [...] > - if (ci->gssauth_use_gssapi < 0) > - ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI; > [...] > + ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI; > > This is a problem, because Postgres' libpq may not be compiled with > GSS support, which is the case of my builds, and the existence of the > connection parameter gsslib depends on if Postgres is compiled with > GSS or not. I think also that this is the only problem, the other > libpq parameter whose existence is defined based on compilation is > krbsrvname, and odbc does not handle it. I have only seen this problem > on Windows, because my Linux builds have GSS support, but I have no > doubt that the problem could be seen there as well. > > Inoue-san, unfortunately I think that your commit is a fault here. > Thanks,
Re: [ODBC] Re: Connection failure with invalid connection option"gsslib" for 09.06.0410
Hi, Though I don't understand the reason why there's a difference between 9.06.0410 and 9.06.0310, I removed the gssauthusegssapi option completely. regards, Hiroshi Inoue On 2017/08/21 15:52, Inoue, Hiroshi wrote: > Hi Michael, > > On 2017/08/21 10:01, Michael Paquier wrote: >> Hi all, >> >> When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I >> lagged behind one release!), I have noticed a failure when connecting >> to a Postgres instance on Windows: >> cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm >> --user test_odbc --pwd passw0rd --port 5444 >> stdout=Connecting odbc : >> DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd}; >> >> stderr=Traceback (most recent call last): >> File "check_odbc.py", line 111, in main >> check_odbc_connection(conn_str) >> File "check_odbc.py", line 15, in check_odbc_connection >> cnxn = pyodbc.connect(conn_str) >> Error: ('08001', '[08001] invalid connection option "gsslib"\n (101) >> (SQLDriverConnect)') > > Unfortunately I can't reproduce it here with dns-less connections. > What is in uninst_std_noimpact_srm? > > regards, > Hiroshi Inoue > >> >> check_odbc.py is a simple wrapper on top of pyodbc that attempts a >> connection to Postgres on Windows, making sure that the DNS defined is >> working correctly. There is nothing fancy in it. >> >> The difference between a failure and a success is only the update of >> the ODBC driver, so I'd like to think that it is its fault here ;) >> >> Looking at the code, I think that this diff in dlg_specific.c, coming >> from commit 3bad6c8e is at fault: >> @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char >> *attribute, const char *value) >> } >> [...] >> -void >> -getDSNdefaults(ConnInfo *ci) >> +static void >> +getCiDefaults(ConnInfo *ci) >> [...] >> - if (ci->gssauth_use_gssapi < 0) >> - ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI; >> [...] >> + ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI; >> >> This is a problem, because Postgres' libpq may not be compiled with >> GSS support, which is the case of my builds, and the existence of the >> connection parameter gsslib depends on if Postgres is compiled with >> GSS or not. I think also that this is the only problem, the other >> libpq parameter whose existence is defined based on compilation is >> krbsrvname, and odbc does not handle it. I have only seen this problem >> on Windows, because my Linux builds have GSS support, but I have no >> doubt that the problem could be seen there as well. >> >> Inoue-san, unfortunately I think that your commit is a fault here. >> Thanks,
I'm confused; does this mean that the new ODBC driver does not support gss/kerberos? The checkin today seems to indicate that. This is something a number of people use. Both for single hop and constrained delegation.
https://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=HEAD
-John
Sent: Thursday, August 24, 2017 6:41:46 AM
To: Michael Paquier
Cc: PostgreSQL mailing lists
Subject: Re: [ODBC] Re: Connection failure with invalid connection option "gsslib" for 09.06.0410
Though I don't understand the reason why there's a difference between
9.06.0410
and 9.06.0310, I removed the gssauthusegssapi option completely.
regards,
Hiroshi Inoue
On 2017/08/21 15:52, Inoue, Hiroshi wrote:
> Hi Michael,
>
> On 2017/08/21 10:01, Michael Paquier wrote:
>> Hi all,
>>
>> When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I
>> lagged behind one release!), I have noticed a failure when connecting
>> to a Postgres instance on Windows:
>> cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm
>> --user test_odbc --pwd passw0rd --port 5444
>> stdout=Connecting odbc :
>> DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd};
>>
>> stderr=Traceback (most recent call last):
>> File "check_odbc.py", line 111, in main
>> check_odbc_connection(conn_str)
>> File "check_odbc.py", line 15, in check_odbc_connection
>> cnxn = pyodbc.connect(conn_str)
>> Error: ('08001', '[08001] invalid connection option "gsslib"\n (101)
>> (SQLDriverConnect)')
>
> Unfortunately I can't reproduce it here with dns-less connections.
> What is in uninst_std_noimpact_srm?
>
> regards,
> Hiroshi Inoue
>
>>
>> check_odbc.py is a simple wrapper on top of pyodbc that attempts a
>> connection to Postgres on Windows, making sure that the DNS defined is
>> working correctly. There is nothing fancy in it.
>>
>> The difference between a failure and a success is only the update of
>> the ODBC driver, so I'd like to think that it is its fault here ;)
>>
>> Looking at the code, I think that this diff in dlg_specific.c, coming
>> from commit 3bad6c8e is at fault:
>> @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char
>> *attribute, const char *value)
>> }
>> [...]
>> -void
>> -getDSNdefaults(ConnInfo *ci)
>> +static void
>> +getCiDefaults(ConnInfo *ci)
>> [...]
>> - if (ci->gssauth_use_gssapi < 0)
>> - ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>> [...]
>> + ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>>
>> This is a problem, because Postgres' libpq may not be compiled with
>> GSS support, which is the case of my builds, and the existence of the
>> connection parameter gsslib depends on if Postgres is compiled with
>> GSS or not. I think also that this is the only problem, the other
>> libpq parameter whose existence is defined based on compilation is
>> krbsrvname, and odbc does not handle it. I have only seen this problem
>> on Windows, because my Linux builds have GSS support, but I have no
>> doubt that the problem could be seen there as well.
>>
>> Inoue-san, unfortunately I think that your commit is a fault here.
>> Thanks,
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [ODBC] Re: Connection failure with invalid connection option"gsslib" for 09.06.0410
I'm confused; does this mean that the new ODBC driver does not support gss/kerberos?
No.
The removed option is for Windows.
As Michael mentioned, libpq on Windows doesn't support GSS.
regards,
Hiroshi Inoue
The checkin today seems to indicate that. This is something a number of people use. Both for single hop and constrained delegation.
https://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=HEAD
-John
From: pgsql-odbc-owner@postgresql.org <pgsql-odbc-owner@postgresql.org> on behalf of Inoue, Hiroshi <h-inoue@dream.email.ne.jp>
Sent: Thursday, August 24, 2017 6:41:46 AM
To: Michael Paquier
Cc: PostgreSQL mailing lists
Subject: Re: [ODBC] Re: Connection failure with invalid connection option "gsslib" for 09.06.0410Hi,
Though I don't understand the reason why there's a difference between
9.06.0410
and 9.06.0310, I removed the gssauthusegssapi option completely.
regards,
Hiroshi Inoue
On 2017/08/21 15:52, Inoue, Hiroshi wrote:
> Hi Michael,
>
> On 2017/08/21 10:01, Michael Paquier wrote:
>> Hi all,
>>
>> When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I
>> lagged behind one release!), I have noticed a failure when connecting
>> to a Postgres instance on Windows:
>> cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm
>> --user test_odbc --pwd passw0rd --port 5444
>> stdout=Connecting odbc :
>> DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd};
>>
>> stderr=Traceback (most recent call last):
>> File "check_odbc.py", line 111, in main
>> check_odbc_connection(conn_str)
>> File "check_odbc.py", line 15, in check_odbc_connection
>> cnxn = pyodbc.connect(conn_str)
>> Error: ('08001', '[08001] invalid connection option "gsslib"\n (101)
>> (SQLDriverConnect)')
>
> Unfortunately I can't reproduce it here with dns-less connections.
> What is in uninst_std_noimpact_srm?
>
> regards,
> Hiroshi Inoue
>
>>
>> check_odbc.py is a simple wrapper on top of pyodbc that attempts a
>> connection to Postgres on Windows, making sure that the DNS defined is
>> working correctly. There is nothing fancy in it.
>>
>> The difference between a failure and a success is only the update of
>> the ODBC driver, so I'd like to think that it is its fault here ;)
>>
>> Looking at the code, I think that this diff in dlg_specific.c, coming
>> from commit 3bad6c8e is at fault:
>> @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char
>> *attribute, const char *value)
>> }
>> [...]
>> -void
>> -getDSNdefaults(ConnInfo *ci)
>> +static void
>> +getCiDefaults(ConnInfo *ci)
>> [...]
>> - if (ci->gssauth_use_gssapi < 0)
>> - ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>> [...]
>> + ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>>
>> This is a problem, because Postgres' libpq may not be compiled with
>> GSS support, which is the case of my builds, and the existence of the
>> connection parameter gsslib depends on if Postgres is compiled with
>> GSS or not. I think also that this is the only problem, the other
>> libpq parameter whose existence is defined based on compilation is
>> krbsrvname, and odbc does not handle it. I have only seen this problem
>> on Windows, because my Linux builds have GSS support, but I have no
>> doubt that the problem could be seen there as well.
>>
>> Inoue-san, unfortunately I think that your commit is a fault here.
>> Thanks,
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Thanks Hiroshi;
We can update our mirror and run through our linux tests and it is entirely possible I'm looking in the wrong place; but it *looks* like the change to connection.c would mean that "gsslib" is not passed to libpq regardless of platform:
--- a/connection.c
Sent: Thursday, August 24, 2017 2:42:42 PM
To: John Kew; Michael Paquier
Cc: PostgreSQL mailing lists
Subject: Re: [ODBC] Re: Connection failure with invalid connection option "gsslib" for 09.06.0410
I'm confused; does this mean that the new ODBC driver does not support gss/kerberos?
No.
The removed option is for Windows.
As Michael mentioned, libpq on Windows doesn't support GSS.
regards,
Hiroshi Inoue
The checkin today seems to indicate that. This is something a number of people use. Both for single hop and constrained delegation.
https://git.postgresql.org/gitweb/?p=psqlodbc.git;a=commit;h=HEAD
-John
From: pgsql-odbc-owner@postgresql.org <pgsql-odbc-owner@postgresql.org> on behalf of Inoue, Hiroshi <h-inoue@dream.email.ne.jp>
Sent: Thursday, August 24, 2017 6:41:46 AM
To: Michael Paquier
Cc: PostgreSQL mailing lists
Subject: Re: [ODBC] Re: Connection failure with invalid connection option "gsslib" for 09.06.0410Hi,
Though I don't understand the reason why there's a difference between
9.06.0410
and 9.06.0310, I removed the gssauthusegssapi option completely.
regards,
Hiroshi Inoue
On 2017/08/21 15:52, Inoue, Hiroshi wrote:
> Hi Michael,
>
> On 2017/08/21 10:01, Michael Paquier wrote:
>> Hi all,
>>
>> When updating the ODBC driver from 09.06.0310 to 09.06.0410 (Yes I
>> lagged behind one release!), I have noticed a failure when connecting
>> to a Postgres instance on Windows:
>> cmd=c:/python27/python check_odbc.py --dsn uninst_std_noimpact_srm
>> --user test_odbc --pwd passw0rd --port 5444
>> stdout=Connecting odbc :
>> DSN=uninst_std_noimpact_srm;Uid=test_odbc;Pwd={passw0rd};
>>
>> stderr=Traceback (most recent call last):
>> File "check_odbc.py", line 111, in main
>> check_odbc_connection(conn_str)
>> File "check_odbc.py", line 15, in check_odbc_connection
>> cnxn = pyodbc.connect(conn_str)
>> Error: ('08001', '[08001] invalid connection option "gsslib"\n (101)
>> (SQLDriverConnect)')
>
> Unfortunately I can't reproduce it here with dns-less connections.
> What is in uninst_std_noimpact_srm?
>
> regards,
> Hiroshi Inoue
>
>>
>> check_odbc.py is a simple wrapper on top of pyodbc that attempts a
>> connection to Postgres on Windows, making sure that the DNS defined is
>> working correctly. There is nothing fancy in it.
>>
>> The difference between a failure and a success is only the update of
>> the ODBC driver, so I'd like to think that it is its fault here ;)
>>
>> Looking at the code, I think that this diff in dlg_specific.c, coming
>> from commit 3bad6c8e is at fault:
>> @@ -790,64 +806,34 @@ copyCommonAttributes(ConnInfo *ci, const char
>> *attribute, const char *value)
>> }
>> [...]
>> -void
>> -getDSNdefaults(ConnInfo *ci)
>> +static void
>> +getCiDefaults(ConnInfo *ci)
>> [...]
>> - if (ci->gssauth_use_gssapi < 0)
>> - ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>> [...]
>> + ci->gssauth_use_gssapi = DEFAULT_GSSAUTHUSEGSSAPI;
>>
>> This is a problem, because Postgres' libpq may not be compiled with
>> GSS support, which is the case of my builds, and the existence of the
>> connection parameter gsslib depends on if Postgres is compiled with
>> GSS or not. I think also that this is the only problem, the other
>> libpq parameter whose existence is defined based on compilation is
>> krbsrvname, and odbc does not handle it. I have only seen this problem
>> on Windows, because my Linux builds have GSS support, but I have no
>> doubt that the problem could be seen there as well.
>>
>> Inoue-san, unfortunately I think that your commit is a fault here.
>> Thanks,
--
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Re: [ODBC] Re: Connection failure with invalid connection option"gsslib" for 09.06.0410
On Fri, Aug 25, 2017 at 7:34 AM, John Kew <jkew@tableau.com> wrote: > Thanks Hiroshi; Top-posting is not the recommended way of posting on those mailing lists. > We can update our mirror and run through our linux tests and it is entirely > possible I'm looking in the wrong place; but it *looks* like the change to > connection.c would mean that "gsslib" is not passed to libpq regardless of > platform: Making this parameter never used in is a bad idea as well. It should be conditional. It seems to me that Postgres ODBC should track if libpq is compiled with GSS or not, and then allow the parameter to be passed down or not. -- Michael
Re: [ODBC] Re: Connection failure with invalid connection option"gsslib" for 09.06.0410
Hi Michael, On 2017/08/25 22:02, Michael Paquier wrote: > On Fri, Aug 25, 2017 at 7:34 AM, John Kew <jkew@tableau.com> wrote: >> Thanks Hiroshi; > Top-posting is not the recommended way of posting on those mailing lists. > >> We can update our mirror and run through our linux tests and it is entirely >> possible I'm looking in the wrong place; but it *looks* like the change to >> connection.c would mean that "gsslib" is not passed to libpq regardless of >> platform: > Making this parameter never used in is a bad idea as well. It should > be conditional. It seems to me that Postgres ODBC should track if > libpq is compiled with GSS or not, and then allow the parameter to be > passed down or not. Honestly I don't like this option. The option had been meaningless for a long time and I almost forget the meaning. Users who want to use gssapi authentication on Windows have used sspi library. When libpq on Windows happens to be compiled with GSS and you want to use the GSS library for gssapi authentication, you can add pqopt option e.g. ;pqopt={gsslib=gssapi}. regards, Hiroshi Inoue regards, Hiroshi Inoue
Re: [ODBC] Re: Connection failure with invalid connection option"gsslib" for 09.06.0410
On Sat, Aug 26, 2017 at 7:01 AM, Inoue, Hiroshi <h-inoue@dream.email.ne.jp> wrote: > When libpq on Windows happens to be compiled with GSS and you want to use > the GSS library for gssapi authentication, you can add pqopt option e.g. > ;pqopt={gsslib=gssapi}. Indeed, I forgot this possibility (personally I don't use this option). So I am fine for the complete removal as done by 833dbb0a. I'll patch my builds and test, but I think that this should be enough to make things back on track again. -- Michael