Re: 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? 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(at)postgresql(dot)org <pgsql-odbc-owner(at)postgresql(dot)org> on behalf of Inoue, Hiroshi <h-inoue(at)dream(dot)email(dot)ne(dot)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.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,

--
Sent via pgsql-odbc mailing list (pgsql-odbc(at)postgresql(dot)org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc