Repository navigation
Default configuration path falls back to the current directory when the home directory cannot be determined #583
Description
Describe the bug
When MICROCKS_CONFIG_DIR is unset and the CLI cannot determine the user's home directory, DefaultConfigDir in pkg/config/localconfig.go discards the error returned by getHomeDir() and returns an empty string with no error.
DefaultLocalConfigPath then constructs the configuration path using this empty directory. Instead of returning an error or selecting a documented fallback, the resulting path can be the relative path config.
This creates an unexpected dependency on the process's current working directory. Commands that load or save local configuration may consequently resolve the configuration file relative to whichever directory the CLI was launched from, rather than using a stable, user-specific configuration directory.
Depending on the command and its execution path, this could cause the CLI to read an unintended file, create configuration in an unexpected location, or fail in a way that obscures the underlying problem. If the relative file contains authentication data, using an unintended location could also create a credential-handling risk.
Expected behavior
The CLI should not silently accept an empty configuration directory after home-directory resolution fails.
It should either:
Return a clear, actionable error indicating that the home directory could not be determined; or
Use a documented and deliberate fallback location that does not unexpectedly resolve to a file in the current working directory.
The selected behavior should be consistent for commands that read and write the default configuration.
Actual behavior
The error from getHomeDir() is discarded, and DefaultConfigDir returns an empty path with a nil error. DefaultLocalConfigPath can consequently resolve to the relative path config, allowing subsequent file operations to depend on the current working directory.
How to Reproduce?
-
Build the CLI or a small diagnostic program against the affected source.
-
Create and switch to a temporary working directory that does not contain an existing configuration file.
-
Unset MICROCKS_CONFIG_DIR and the relevant home-directory environment variables. On Windows, unset USERPROFILE; on Unix-like systems, unset HOME.
-
Call config.DefaultLocalConfigPath() or run a CLI command that loads the default local configuration, such as context list.
-
Inspect the resolved path and the command's behavior.
For a direct path-resolution check, call DefaultLocalConfigPath() and print both its returned path and error. Under the affected conditions, the expected reproduction is a relative path such as config with no reported error.
To verify actual file access separately, place a harmless, deliberately malformed test configuration file named config in the temporary working directory and run a command that loads the local configuration. A parsing error can help demonstrate that the relative file is being read. Do not use real configuration files or credentials for this test.
Microcks version or git rev
main
Install method (docker-compose, helm chart, operator, docker-desktop extension,...)
CLI
Additional information
No response
Activity
SafeeImran commentedon Oct 12, 2026
@Harsh4902 what would be your takes on this?