[Bug 59799] New: odbc32: SQLSetConnectAttr returns SQL_ERROR for unknown driver-specific connection attributes instead of forwarding to the driver
http://bugs.winehq.org/show_bug.cgi?id=59799 Bug ID: 59799 Summary: odbc32: SQLSetConnectAttr returns SQL_ERROR for unknown driver-specific connection attributes instead of forwarding to the driver Product: Wine Version: unspecified Hardware: x86-64 OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: odbc Assignee: wine-bugs@list.winehq.org Reporter: arthur.talpaert_winehq@m4x.org Description Per the ODBC specification, the driver manager's SQLSetConnectAttr must forward attributes outside the standard range (≥ SQL_CONNECT_OPT_DRVR_START = 1000) to the underlying driver's SQLSetConnectAttr without validation. Wine's odbc32 implementation has a hardcoded switch over known attribute IDs and returns SQL_ERROR for anything else, logging fixme:odbc:SQLSetConnectAttr unhandled attribute <N>. This breaks every modern SQL Server client built on Microsoft ODBC Driver 17/18, which routinely sets vendor-specific attributes: 1219 — SQL_COPT_SS_ENCRYPT 1224 — SQL_COPT_SS_TRUST_SERVER_CERTIFICATE 1226 — SQL_COPT_SS_APPLICATION_INTENT 1227 — SQL_COPT_SS_MULTI_SUBNET_FAILOVER Steps to reproduce Install Microsoft ODBC Driver 17 for SQL Server (msodbcsql.msi) into a Wine prefix. Run any application that calls SQLSetConnectAttr with SQL_COPT_SS_TRUST_SERVER_CERTIFICATE (1224) on the connection handle before SQLConnect. Concrete reproducer: GMC PaDok 5.0.5.0 client installer (setup_gmcpadok_5050.exe) pointed at any SQL Server with a default self-signed TLS cert. Expected SQLSetConnectAttr forwards the call to the driver's SQLSetConnectAttr, which honors it (the MS driver does). SQLConnect then proceeds with the trust-cert flag set. Actual SQLSetConnectAttr returns SQL_ERROR (-1). SQLGetDiagRec returns SQL_NO_DATA (Wine populated no diagnostic record). The application gives up before any TCP connection to SQL Server is attempted. Trace excerpt (with WINEDEBUG=-fixme,+odbc) 0214:trace:odbc:SQLSetConnectAttr (ConnectionHandle …, Attribute 103, Value 0000000F, …) Returning 0 0214:trace:odbc:SQLSetConnectAttr (ConnectionHandle …, Attribute 113, Value 0000001E, …) Returning 0 0214:trace:odbc:SQLSetConnectAttr (ConnectionHandle …, Attribute 1224, Value 00000001, …) 0214:fixme:odbc:SQLSetConnectAttr unhandled attribute 1224 0214:trace:odbc:SQLSetConnectAttr Returning -1 0214:trace:odbc:SQLGetDiagRec (…) Returning 100 0214:trace:odbc:SQLFreeHandle (HandleType 2, …) Proposed fix Wine's odbc32 should forward SQLSetConnectAttr calls for attributes ≥ 1000 (SQL_CONNECT_OPT_DRVR_START) directly to the underlying driver via the proxy table, without validation. Attributes < 1000 that are not in the manager's known set may still be rejected with SQL_ERROR, but with a populated diagnostic record per spec. Workarounds None known. WINEDLLOVERRIDES can replace odbc32 itself, but Microsoft ODBC Driver 17 doesn't ship its own driver manager. Installing native macOS unixODBC + Microsoft's native msodbcsql17 and putting Wine into Unix-proxy mode (libodbc.dylib) is untested and would also still hit downstream FILESTREAM-IOCTL issues unrelated to this bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59799 --- Comment #1 from Hans Leidekker <hans@meelstraat.net> --- Those attributes should be forwarded to the driver but it's not straightforward because the driver isn't loaded until a connection is made and these attributes are of course set before a connection is made. We'll have to store them so we can apply them later when the connection is actually made. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59799 --- Comment #2 from Hans Leidekker <hans@meelstraat.net> --- Created attachment 81041 --> http://bugs.winehq.org/attachment.cgi?id=81041 patch Can you try this patch? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59799 --- Comment #3 from Arthur Talpaert <arthur.talpaert_winehq@m4x.org> --- (In reply to Hans Leidekker from comment #2)
Created attachment 81041 [details] patch
Can you try this patch?
Thanks for the fast turnaround, Hans — and for the clear explanation of why the attributes can't be forwarded immediately at SQLSetConnectAttr time. For end-to-end validation against the original reproducer, the GMC PaDok client installer is publicly downloadable (no login) from the vendor's customer page: https://www.gmc-systems.de/index.php/service/kundenbereich-gmc-padok/index.h... Grab "Installation GMC PaDok Client" (setup_gmcpadok_5050.exe, ~430 MB). The path that hits the bug is: launch the installer, advance to the SQL Server Verbindungsaufbau screen, tick Manuelle Eingabe, enter the host:port of any SQL Server with a default self-signed cert (e.g. <host>,1433), pick ODBC Driver 17 for SQL Server in the dropdown, Weiter. On stock Wine 10 the call fails at attribute 1224 (SQL_COPT_SS_TRUST_SERVER_CERTIFICATE); PaDok surfaces "Konfigurationsdatenbank nicht erreichbar". If you'd rather have a minimal C reproducer that doesn't pull in the whole PaDok stack: SQLHENV env; SQLAllocHandle(SQL_HANDLE_ENV, NULL, &env); SQLSetEnvAttr(env, SQL_ATTR_ODBC_VERSION, (void*)SQL_OV_ODBC3, 0); SQLHDBC dbc; SQLAllocHandle(SQL_HANDLE_DBC, env, &dbc); SQLSetConnectAttr(dbc, SQL_ATTR_LOGIN_TIMEOUT, (SQLPOINTER)15, 0); SQLSetConnectAttr(dbc, SQL_ATTR_CONNECTION_TIMEOUT, (SQLPOINTER)30, 0); SQLSetConnectAttr(dbc, SQL_COPT_SS_TRUST_SERVER_CERTIFICATE, (SQLPOINTER)1, 0); SQLDriverConnect(dbc, NULL, (SQLCHAR*)"Driver={ODBC Driver 17 for SQL Server};Server=<host>;Database=master;Uid=<user>;Pwd=<pwd>;", SQL_NTS, NULL, 0, NULL, SQL_DRIVER_NOPROMPT); Same code path as PaDok; the third SQLSetConnectAttr is where the fixme fires on stock Wine 10. Testing 1224 alone is sufficient to validate the storage-and-replay logic — the other SS attributes in the same range (1219 / 1226 / 1227) follow identical semantics. I'm not currently set up to build Wine from source, so I can't validate the patch directly on my end. I'll watch this bug and pick up the fix once it lands in a Sikarugir release. Thanks again! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59799 --- Comment #4 from Hans Leidekker <hans@meelstraat.net> --- Patch was committed as 5380961f41a13c3c498c365520dc6a584ea8e09d and is included in Wine 11.10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59799 --- Comment #5 from Hans Leidekker <hans@meelstraat.net> --- Can you confirm that this bug is fixed in current Wine? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla