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

[Suggestion] SELinux compatibility for podman-host (VS Code integration) #1559

Open
JaneSmith opened this issue Sep 17, 2024 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@JaneSmith
Copy link

JaneSmith commented Sep 17, 2024

Is your feature request related to a problem? Please describe.

I've recently set up the VSCode Flatpak, to work in both Distrobox and dev containers, using the podman-host wrapper script.

Following the instructions on the Distrobox's Integrate VSCode and Distrobox page, I was able to get containers working just fine with VSCode+Distrobox. No issues there. Thank you for providing a way to do this!

The problems began when I started trying to use VSCode with ordinary devcontainers, i.e. specified using devcontainer.json, managed using the VSCode "Dev Containers" extension, and completely unrelated to Distrobox. It simply wasn't working. Containers would fail to build with unclear errors. I found many threads discussing this, such as this one, this one, and this one.

The tl;dr is that VSCode's devcontainers don't play nicely with Podman and SELinux, and the containers need to have --security-opt=label=disable and --userns=keep-id set. The general solution followed seems to be to modify the project's devcontainer.json file to add these settings in the runArgs block. This works, but it's not a clean solution as it means putting machine-specific hacks into what should be a shared file for all contributors to use.

Someone has suggested a better solution of putting these adjustments into a podman wrapper script, providing an example script here: https://gist.github.com/theonlyfoxy/d7a3d8e90493a00faaef1cbd782da196 By moving it to the wrapper script, the devcontainer.json stays clean, and it's easier to work with other people's projects that use a foreign devcontainer.json file.

Describe the solution you'd like

I'd like to suggest that the Distrobox podman-host wrapper script be updated to incorporate similar changes for SELinux compatibility:

For non-Distrobox containers, have the podman-host wrapper script check if it's running on an SELinux-enabled system, and if so set --security-opt=label=disable and perhaps --privileged as done in this alternative wrapper script.

Describe alternatives you've considered

I could just use their wrapper script directly, but then I'll lose the Distrobox support. I could edit the script myself, but then it'll be harder to manage when moving machines or reinstalling. And I feel like the Distrobox wrapper script is generally more discoverable for people, so it would be good if it could just provide a universal solution. Surely I can't be the only one that set up VS Code following the Distrobox guide? The guide is the first Google search result for "vscode flatpak distrobox", and ranks highly for other searches related to VSCode, Flatpak, and containers.

I know this isn't strictly a Distrobox issue, as the wrapper script does work just fine for Distrobox. But the wrapper script also tries to provide a way to transparently access Podman for non-Distrobox use-cases. And that's where the problem is. Rather than switching back and forth between a "Distrobox Podman wrapper" and a separate "Dev Containers Podman wrapper", it would be ideal to have one wrapper that handles all circumstances. Something that Just Works.

Additional context

I'm running Fedora Silverblue 40.20240526.0. Fedora Silverblue is a popular Linux distro for container-based workflows, and being Fedora it of course uses SELinux. This issue would affect anyone trying to use VSCode devcontainers with an SELinux distro and the podman-host wrapper script.

@JaneSmith JaneSmith added the enhancement New feature or request label Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant