fix: use plain open() when creating empty config files

[baxeaz]

Fixes: N/A — no tracking issue

What was the problem/requirement? (What/Why)

ConfigurationManager._ensure_config_file creates an empty <AdaptorName>.json on first access if one does not yet exist. That create path goes through secure_open(), which on Windows replaces the file's DACL with a single non-inheriting ACE granting only the current owner SID FILE_GENERIC_READ | FILE_GENERIC_WRITE | DELETE (see set_file_permissions_in_windows in _secure_open.py).

The effect is that the config file's ACL stops following the parent directory's inheritable ACLs and is permanently bound to the SID of whichever account happened to first create it. If that file is later accessed by any other account — even one that would have had inherited access from the parent directory — the open fails with PermissionError. It also runs counter to what most users will reasonably expect from filesystem permissions on an ordinary config file.

There is no documented requirement for adaptor config files to be owner-only at the file level. The directories these files live in (<adaptor module dir>/, ~/.openjd/adaptors/<name>/, %PROGRAMDATA%\openjd\adaptors\<name>\) already restrict access via their own ACLs.

What was the solution? (How)

Switch the create path in _ensure_config_file to use plain open(filepath, mode="w", encoding="utf-8") and let normal filesystem permission rules apply. This matches the call style used by every other open() write in this package (e.g., frontend_runner.py for the bootstrap output file).

The other secure_open call sites (the connection file in _background/backend_runner.py and the log buffer in _background/log_buffers.py) are intentionally unchanged.

What is the impact of this change?

On Windows, newly created adaptor config files inherit ACLs from their parent directory rather than receiving an owner-only DACL. On POSIX, behavior is unchanged in practice — secure_open was already only setting S_IWUSR | S_IRUSR via os.open, which open() of a fresh file effectively produces under typical default umasks for the directories these files land in.

No public API changes. The secure_open helper itself is untouched and remains available for callers (including the connection-file and log-buffer call sites) that want owner-only DACLs.

How was this change tested?

• hatch run test — 439 passed, 36 skipped (Posix-only tests skipped on Windows host), 91.94% coverage.

• hatch run lint — ruff check, black --check, and mypy all clean.

• Updated test/openjd/adaptor_runtime/unit/adaptors/configuration/test_configuration_manager.py::TestEnsureConfigFile::test_create to patch builtins.open instead of secure_open and to assert the new keyword (mode="w" rather than open_mode="w").

• Have you run the unit tests? Yes (see above).

Was this change documented?

• Are relevant docstrings in the code base updated? No docstrings reference the removed secure_open call; none required updates.

Is this a breaking change?

No. _ensure_config_file is a module-private helper (leading underscore) and ConfigurationManager's public API is unchanged. Callers outside the package do not depend on the file-permission side effect of the create path; the public read/write APIs (get_default_config, get_user_config, build_config, etc.) behave identically.

Does this change impact security?

The change relaxes a previously-enforced owner-only DACL on Windows for a single file-create call site. The argument for doing so is that:

1. The file in question is a config file whose containing directories already have appropriate access control.
2. The previous behavior was inconsistent — the override only applied when the runtime created the file; if an admin or packager pre-placed <AdaptorName>.json in the package directory or elsewhere, no DACL override was ever applied to it. So no part of the system was relying on this file's ACL as a security boundary.
3. The owner-only DACL was actively harmful in cross-account access scenarios, where the SID baked into the ACE no longer matches the accessing account.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.