Skip to content

Default configuration path falls back to the current directory when the home directory cannot be determined #583

Open

Description

@SafeeImran

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?

  1. Build the CLI or a small diagnostic program against the affected source.

  2. Create and switch to a temporary working directory that does not contain an existing configuration file.

  3. Unset MICROCKS_CONFIG_DIR and the relevant home-directory environment variables. On Windows, unset USERPROFILE; on Unix-like systems, unset HOME.

  4. Call config.DefaultLocalConfigPath() or run a CLI command that loads the default local configuration, such as context list.

  5. 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.

Image

Microcks version or git rev

main

Install method (docker-compose, helm chart, operator, docker-desktop extension,...)

CLI

Additional information

No response

Activity

  1. SafeeImran commented on Oct 12, 2026

    @SafeeImran
    Author

    @Harsh4902 what would be your takes on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions