adbc-driver-snowflake: authentication to Snowflake fails from Linux container for certain substrings in password

[torbjoernk]

What happened?

I have a functional script to query data from a Snowflake database - at least it's functional when running on Windows.

As soon as I run it within a Linux-based container, it fails due to authentication issues. I'm using the same credentials.

I also tried using the Snowflake CLI within an Ubuntu container with the same credentials and it failed as well.

Stack Trace

When run within a Linux-based container:

ERRO[0000]auth.go:364 gosnowflake.authenticate Authentication FAILED
Traceback (most recent call last):
  File "/src/api/data_importers/pppm_data_collector.py", line 305, in <module>
    asyncio.run(_test(True))
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/src/api/data_importers/pppm_data_collector.py", line 299, in _test
    await rdc.update_local_data_thread()  # Runs the code in a separate thread
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/src/api/data_importers/base_importer_class.py", line 304, in update_local_data_thread
    await asyncio.to_thread(asyncio.run, self.update_local_data_async(time_horizon))
  File "/usr/local/lib/python3.12/asyncio/threads.py", line 25, in to_thread
    return await loop.run_in_executor(None, func_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 194, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
  File "/src/api/data_importers/pppm_data_collector.py", line 269, in update_local_data_async
    adbc_sf.connect(snowflake_master_data_uri) as snowflake_master_conn,
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/pc/.venv/lib/python3.12/site-packages/adbc_driver_snowflake/dbapi.py", line 120, in connect
    conn = adbc_driver_manager.AdbcConnection(db, **(conn_kwargs or {}))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "adbc_driver_manager/_lib.pyx", line 705, in adbc_driver_manager._lib.AdbcConnection.__init__
  File "adbc_driver_manager/_lib.pyx", line 260, in adbc_driver_manager._lib.check_error
adbc_driver_manager.OperationalError: IO: 390100 (08004): Incorrect username or password was specified.

When run within an k8s cluster, the stack trace is the same, but the final error message is slightly different:

adbc_driver_manager.OperationalError: IO: 390201 (08004): The requested warehouse does not exist or not authorized.

How can we reproduce the bug?

Potentially, by using a password with one of these substrings: $6, *$ and/or .>.

Alternatives Tested

Using the snowflake-python-connector package from Snowflake does not give any errors - neither on Windows nor within a Linux container.

Environment/Setup

Python 3.12.8
adbc-driver-manager 1.4.0
adbc-driver-snowflake 1.4.0

[torbjoernk]

Can it be that adbc-driver-snowflake uses the same authentication library that the official Snowflake CLI uses?

With a different user and a password that does not contain any of these mentioned substrings everything works as intended - both the Snowflake CLI as well as the adbc-snowflake-driver.

I'll also report this to Snowflake.

[lidavidm]

It is based on gosnowflake (https://github.com/snowflakedb/gosnowflake/)

It appears the CLI is written in Python. But we don't process the password in any way other than passing it on to gosnowflake. So I would guess, at least as a first hypothesis, that it's an upstream bug

[torbjoernk]

I have to admit an embarrassing mistake on my end on how Bash handles variables. We are using pydantic to read in various settings from the environment.

Minimal example of the underlying problem:
pydantic_test.py:

from pydantic_settings import BaseSettings


class A(BaseSettings):
    VAR_A: str
    VAR_B: str

if __name__ == "__main__":
    a = A()
    print(f"{a.VAR_A=}")
    print(f"{a.VAR_B=}")

pc@3e4078e998cc:/src$ export VAR_A=abc
pc@3e4078e998cc:/src$ export VAR_B=d$VAR
pc@3e4078e998cc:/src$ python pydantic_test.py
a.VAR_A='abc'
a.VAR_B='d'
pc@3e4078e998cc:/src$ export VAR_B=d\$VAR
pc@3e4078e998cc:/src$ python pydantic_test.py
a.VAR_A='abc'
a.VAR_B='d$VAR'

Sorry for the noise 🙏

[lidavidm]

Ah, thanks for following up!