[Bug] Init of ClientApplication fails on read only filesystems when msal-extensions is installed since 1.32.0

[nluedema]

Describe the bug
After upgrading to 1.32.0, initializing ClientApplication fails with the following error when also msal-extensions is installed:

Traceback (most recent call last):
  File "//confidential_client_sample.py", line 42, in <module>
    global_app = msal.ConfidentialClientApplication(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/msal/application.py", line 664, in __init__
    _msal_extension_check()
  File "/usr/local/lib/python3.12/site-packages/msal/application.py", line 201, in _msal_extension_check
    from msal_extensions import __version__ as v
  File "/usr/local/lib/python3.12/site-packages/msal_extensions/__init__.py", line 11, in <module>
    from .cache_lock import CrossPlatLock
  File "/usr/local/lib/python3.12/site-packages/msal_extensions/cache_lock.py", line 8, in <module>
    import portalocker
  File "/usr/local/lib/python3.12/site-packages/portalocker/__init__.py", line 2, in <module>
    from .utils import (
  File "/usr/local/lib/python3.12/site-packages/portalocker/utils.py", line 418, in <module>
    class BoundedSemaphore(LockBase):
  File "/usr/local/lib/python3.12/site-packages/portalocker/utils.py", line 441, in BoundedSemaphore
    directory: str = tempfile.gettempdir(),
                     ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/tempfile.py", line 315, in gettempdir
    return _os.fsdecode(_gettempdir())
                        ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/tempfile.py", line 308, in _gettempdir
    tempdir = _get_default_tempdir()
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/tempfile.py", line 223, in _get_default_tempdir
    raise FileNotFoundError(_errno.ENOENT,
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']

We noticed this problem after our get_token calls started to fail for a azure.identity.ClientSecretCredential in fresh Docker builds for containers with a read-only filesystem. We traced the problem back to an update of msal from version 1.31.1 to 1.32.0. As you can see from the stack trace, the call to _msal_extension_check leads to portalocker being imported, which calls tempfile.gettempdir(). Calls to tempfile.gettempdir() fail on read-only filesystems.

To Reproduce
I was able to reproduce the error with Docker and your confidential_client_sample.py sample.
Here the Dockerfile:

FROM python:3.12.9-slim-bookworm

RUN pip install msal python-dotenv msal-extensions

COPY confidential_client_sample.py confidential_client_sample.py
COPY .env .env

CMD ["python","confidential_client_sample.py"]

Then run the following:

docker build . -t test
docker run --read-only test:latest

Which will result in the traceback shown above.

Expected behavior
Successfully acquiring a token.

What you see instead

Traceback (most recent call last):
  File "//confidential_client_sample.py", line 42, in <module>
    global_app = msal.ConfidentialClientApplication(
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/msal/application.py", line 664, in __init__
    _msal_extension_check()
  File "/usr/local/lib/python3.12/site-packages/msal/application.py", line 201, in _msal_extension_check
    from msal_extensions import __version__ as v
  File "/usr/local/lib/python3.12/site-packages/msal_extensions/__init__.py", line 11, in <module>
    from .cache_lock import CrossPlatLock
  File "/usr/local/lib/python3.12/site-packages/msal_extensions/cache_lock.py", line 8, in <module>
    import portalocker
  File "/usr/local/lib/python3.12/site-packages/portalocker/__init__.py", line 2, in <module>
    from .utils import (
  File "/usr/local/lib/python3.12/site-packages/portalocker/utils.py", line 418, in <module>
    class BoundedSemaphore(LockBase):
  File "/usr/local/lib/python3.12/site-packages/portalocker/utils.py", line 441, in BoundedSemaphore
    directory: str = tempfile.gettempdir(),
                     ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/tempfile.py", line 315, in gettempdir
    return _os.fsdecode(_gettempdir())
                        ^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/tempfile.py", line 308, in _gettempdir
    tempdir = _get_default_tempdir()
              ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/tempfile.py", line 223, in _get_default_tempdir
    raise FileNotFoundError(_errno.ENOENT,
FileNotFoundError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']

The MSAL Python version you are using
1.32.0

Additional context
I assume that this will also affect quite a few others, since running containers with a read-only filesystem is a security best practice.

[rayluo]

Thanks for reporting. Taking a look.

[rayluo]

Thanks Niklas (@nluedema) for the detailed report. I am able to reproduce the issue. However, the root cause seems to be the msal-extensions 1.2.0 package (always?) failed inside a read-only container. You can reproduce without any test script; you can just build an image with msal-extensions 1.2.0 and then run python -c "import msal_extensions" inside and see the same error.

So, my follow-up question is, were you actually using msal_extensions package inside your read-only container before we released MSAL 1.32?

• If not, then your quick workaround would be to remove that dependency from your docker image. The purpose of msal-extensions is (1) token encryption when token cache is persisted on disk; and (2) sharing disk-based token cache with other processes. Since you intend to run your container with read-only mode, neither of those functionalities is useful to you.
• If you were indeed somehow using msal_extensions inside a read-only container, I would love to hear more. But then please create a new issue in MSAL Extensions's repo.

[nluedema]

Thanks for taking a look so quickly Ray Luo (@rayluo). We are not directly using msal, but we are using it as a dependency of the azure-identity library. azure-identity requires both msal and msal-extensions. We have been using azure-identity in read-only containers for quite some time now, but I assume msal-extensions never got imported since we don't use any disk persistence features. msal-extensions started being imported after installing azure-identity with msal 1.32.0 as a dependency. So no, we haven't been using msal-extensions.

I just made some tests installing azure-identity and then afterwards uninstalling msal-extensions. Looks like in a container it works and it doesn't break azure-identity. Running it locally on my machine breaks azure-identity, as msal-extensions seems to be used for Keychain access.

What I gather from this is that this is an issue that might have to be tackled by azure-identity?

[rayluo]

Thanks for the more context. That makes sense.

No, this issue will not be tackled by azure-identity. The underlying issue is actually one of msal-extensions's dependencies, portalocker, cannot be run inside a read-only container (you can reproduce it with the same steps in my previous message, but replace msal-extensions with portalocker). And we are planning to drop that dependency in MSAL Extensions anyway. Please subscribe that issue and/or repo for its new release notification.

[nluedema]

Ohh that's great, with portalocker being optional the problem would be solved! Then we will pin msal to 1.31.1 for now and upgrade once msal-extensions 1.3.0 is released. Thank you so much for your support!

[rayluo]

Closed by AzureAD/microsoft-authentication-extensions-for-python#138
Latest MSAL Python 1.32.0 and msal-extensions 1.3.0 shall not run into this issue.