Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Potential footgun by allowing Distrobox applications to write to host XDG_DATA_ and XDG_CONFIG_HOME directories by default, especially with apps that install into $HOME #1067

Open
Cloudwalk9 opened this issue Nov 21, 2023 · 0 comments
Labels
question Further information is requested

Comments

@Cloudwalk9
Copy link

Distrobox allows running arbitrary distributions on containers and run their apps seamlessly with the host. The default behavior is to use the host's $HOME in containers. This is usually fine. But there's several issues with this approach which can lead to subtle unpredictable behavior in some edge cases.

  • The unpredictability can arise from different package versions between host and container reading and writing to user config, causing unpredictable behavior and failures.

  • Some applications are installed under the local user, and one may want to use Distrobox to segment them and avoid cluttering host's .local, and still have access to their .bashrc and ssh keys, or w/e. But by using --home, the seamless integration is not so seamless anymore.

I'm sure we'd like to keep $HOME set to host $HOME, but for apps to keep to their own container as probably intended. There's no middle ground between using --home and not using --home. This can be achieved by leveraging the XDG environment variables.

The solution given to me was to just use --env to pass them directly. This is tedious. I instead proposed a flag to automate this and fill in that middle ground. Any solution should not disrupt the prevailing use case of Distrobox but should nevertheless at least guarantee (to the best of its abilities) a clean configuration environment if needed, while still integrating with the host.

After an unreasonably heated discussion in the Matrix chat, I want to at least open discussion about this problem a little more publicly.

@Cloudwalk9 Cloudwalk9 added the question Further information is requested label Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant