Re: Re: Connection failure with invalid connection option "gsslib" for 09.06.0410

Hi John,

On 2017/08/25 1:27, John Kew wrote:
>
>
> 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(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