[SEC-6587] Databricks CLI Tool Config File inherits default system umask

[shreyas-goenka]

This PR makes changes so that .databrickscfg file has user only read write permissions at create time rather than the original workflow which is create file -> write token to file -> change permission to user only read write (0o600) which can be used by an adversary to read the token

Tested manually by looking that the permissions on the file after its creation

[fjakobs]

Code change looks good but please also add a unit test to tests/configure/test_provider.py to verify that the file permissions are indeed 600.

[pietern]

@shreyas-goenka Did you test or hypothesize how this works on Windows? It looks risky / like it might break on Windows.

[shreyas-goenka]

@pietern I did not think about this testing on windows. A quick look at the docs leads me to believe the happy path mostly should be fine i.e. when no .databrickscfg file exists and users use the cli, one with the right permissions should be created.

I believe this because

1. os.open: works for both windows and unix
2. os.path.exists: The os availability is not specified in the docs but very highly likely it works on both systems
3. Before my code we had os.chmod calls which did not break this workflow (Only true if a user actually used windows with our cli and it worked :P)

In any case the python os docs don't make it clear what the behavior would be here. Do we have a windows VM to do a quick test?

[pietern]

Yes, I'll be in touch with details.

[fjakobs]

Why not just add windows to the test matrix in https://github.com/databricks/databricks-cli/blob/main/.github/workflows/push.yml#L21 ?

[pietern]

@fjakobs We should, once 1) existing failing tests on Windows are fixed, and 2) we trim the # of builds (no need to test all Python versions on Windows, just 1 of them would be sufficient). Thinking about 2), it's probably easier to define a dedicated Windows test job...