Support SELinux enabled systems #1333
Comments
|
You could set |
chrmarti
added
containers
|
There are now also built-in ways of connecting to a Docker volume:
|
|
What is the current recommended work around for SELinux? I'm trying to open a host workspace in a container using the dev container infrastructure built into vscode-remote. It seems that on systems with SELinux, this can only be accomplished with a bind mount and Short of cloning a repository to a volume, is there a better workflow that still involves vscode-remote? |
|
@sclel016 Those people who invented SeLinux provided a tool that gives to rootless users the same power as the root user has without compromising security - FUSE and FUSE mount Look at the contributor's list of both projects. It is an important part of Rootles Docker and Podman and comes to Linux as a dependency. Using FUSE mount implementation instead of Linux mount solves the problem. |
|
@sclel016 Docker graph driver overlayfs + fuse/overlayfs should work for you on any Linux - fuse-overlayf storage driver should work for you on any Linux |
|
Hello, I am using VSCode 1.57.1 and Podman 3.1.2. I managed to mount my SELinux protected directory using this However, I am not able to use the I am not sure if it used to worked but I remember doing something like that previously (where It fails with this error: Is it expected? |
|
Could it be linked to #5007 ? |
|
Hello ! Is there a problem with |
|
@lovasoa Make sure to clear the |
|
@langdon You can try it:
|
|
I ran into this for the first time just now as I'm setting up a new environment using Fedora 35. If you're making use of one of the existing devcontainer configurations or wrote your own that makes use of a services:
app:
# ...etc
volumes:
- ..:/workspace:ZHopefully a more official solution can be made available at some point. I'm not sure if an environment specific fix should exist in a repository's configuration file, as colleagues/collaborators might use very different environments, but at least for now this can hopefully help you get back to working on your project :). |
For docker compose volume, need to suffix with :z due to selinux configuration. Without the suffix, the folder cannot open in container due no permission. microsoft/vscode-remote-release#1333
ghost
mentioned this issue
|
ha ha of course it was selinux |
|
I'm working on fedora 37 and getting this. The manual bind mount doesn't work, the files inside the container are owned by root |
Could you share (a snippet of) your |
|
Hey @jibsaramnim, this is my devcontainer.json {
"name": "Existing Dockerfile",
"build": {
"context": "..",
"dockerfile": "../Dockerfile.dev"
}
}Dockerfile.dev I also tried {
"name": "Existing Dockerfile",
"build": {
"context": "..",
"dockerfile": "../Dockerfile.dev"
},
"workspaceMount": "",
"runArgs": ["--volume=${localWorkspaceFolder}:/workspaces/${localWorkspaceFolderBasename}:Z"]
}but both ways have the same problem, the workspace files are owned by root EDIT: Using docker 20.10.21 via docker desktop. |
Correct me if I'm wrong, but are you using a non-vscode container image? There might be a difference in user IDs that causes the issue for you. Alternatively, you could try setting Could you perhaps try starting with one of VSCode's container presets? In my case with the exact same |
|
FWIW adding Using the node+typescript preset + runArgs does not work either, files are still owned by root. {
"name": "Node.js & TypeScript",
"image": "mcr.microsoft.com/devcontainers/typescript-node:0-18",
"workspaceMount": "",
"runArgs": ["--volume=${localWorkspaceFolder}:/workspaces/${localWorkspaceFolderBasename}:Z"]
} |
|
I played around with volumes with |
There might be something (permission related, perhaps?) going on on your particular system -- who owns the files you are trying to edit? I just tried it with the same node+typescript preset you mentioned in a test directory, just modifying {
"name": "Node.js & TypeScript",
"image": "mcr.microsoft.com/devcontainers/typescript-node:0-18",
"workspaceMount": "",
"runArgs": [
"--volume=${localWorkspaceFolder}:/workspaces/${localWorkspaceFolderBasename}:Z"
]
}node ➜ /workspaces/temp $ ls -Z
system_u:object_r:container_file_t:s0:c390,c979 readme.md system_u:object_r:container_file_t:s0:c390,c979 test.js
node ➜ /workspaces/temp $ ls -la
total 0
drwxr-xr-x. 1 node node 58 Dec 12 08:30 .
drwxr-xr-x. 1 root root 8 Dec 12 08:32 ..
drwxr-xr-x. 1 node node 34 Dec 12 08:30 .devcontainer
-rw-r--r--. 1 node node 0 Dec 12 08:30 readme.md
-rw-r--r--. 1 node node 0 Dec 12 08:30 test.jsAre you running |
|
Files are owned by my user account. I'm using docker-desktop via the rpm package.
This is what I get inside the container This is outside the container @jibsaramnim Are your selinux labels the same inside+outside the container? This is what I meant by I don't think docker is changing the labels correctly. |
|
@jibsaramnim What is the output of |
They are yes: node ➜ /workspaces/temp $ ls -lZ
total 0
-rw-r--r--. 1 node node system_u:object_r:container_file_t:s0:c390,c979 0 Dec 12 08:30 readme.md
-rw-r--r--. 1 node node system_u:object_r:container_file_t:s0:c390,c979 0 Dec 12 08:30 test.jsOutside the container: ~/P/temp ❯❯❯ ls -lZ
total 0
-rw-r--r--. 1 davejansen davejansen system_u:object_r:container_file_t:s0:c390,c979 0 12월 12일 17:30 readme.md
-rw-r--r--. 1 davejansen davejansen system_u:object_r:container_file_t:s0:c390,c979 0 12월 12일 17:30 test.js
docker info | grep Security -A3
Security Options:
seccomp
Profile: default
selinuxIn case it helps; I am running Fedora Silverblue 37 with |
|
Cool, that's what I expected. I don't have I temporarily switched to podman and its selinux support works. |
|
@bradydean have you considered |
|
@langdon oh nice, I didn't even know that existed. I'll play around with it. |
|
Well, I'm not really sure what happened, but my files inside the container are owned by root again, even using podman... |
|
Anyways, EDIT: It worked once and only once.. |
|
Is there a real solution now to this? The workarounds I saw all seem to require patching the devcontainer configuration. Which may work for one setup, but not for another. So as the original reported mentioned, I would expect some out-of-the-box support for this. |
|
as a workaround you could set remoteUser to root. example devcontainer.json: {
"remoteUser": "root",
"containerUser": "vscode",
"workspaceMount": "",
"runArgs": ["--volume=${localWorkspaceFolder}:/workspaces/${localWorkspaceFolderBasename}:Z"]
}also see. |
|
I ran into this issue with the Docker package from the official Fedora repository. However, when I switched to using the package from the upstream docker repo, the problem goes away. There's no need to manually set the :z or :Z flag. I am not sure what has change though. |
|
To my understanding that simply drops the SElinux support and runs everything as root. Which might not be everyone's cup of tea. |
This does not work when your image has tooling installed specifically configured for the unprivileged user ( |
|
No I have a feeling why only containerd+ docker are used in the k8s lightweightvm + containterd. There’s a few other containers that are allowed. Basically from what I gather the eventual work around is to assume containers are run under hypervisor (visor now) ignored by demonic and have selinyx ignore all non objects and containers. I believe there’s a system call made in docker that ignores bind/volumes and as the hypervisot intercepts all Linux calls it makes more sense to patch it then break all of docker. Can someone direct me to a github repo they tested this on? I can trace the syscall and see if disabling apparmor seccomp in containers fixes this. This feels like a historical docker issue that it is easier to rewrite a hypervisor then change docker. |
|
So what should be the default minimal addition to So far I've seen 3 versions (excluding the
|
|
Install qVisor run containers in a lightweight hypervisor set SELinux to ignore objects and just binaries. Call it a day. If the containers need to talk to each other there’s tompr or something. Dev containers are made for old school Dockers running root not anything OCI compliant. |
|
|
I have had a nightmare getting VS Code working with dev containers on Fedora Silverblue. I finally got it working with the following in None of the other solutions worked for me. I don't know why they worked for others and not for me. The above, without setting The above wouldn't even let me build the container. I'd just get a "command failed" error with not much useful information. Why is this still not working out of the box in 2024? This issue was opened in 2019! I thought the whole point of dev containers was that the project environment "just works", i.e. a contributor can pull a code repository and VS Code will automatically set up the environment so the contributor can get started. Obviously that doesn't work. And I find it quite strange that I have to resort to machine-specific hacks in the devcontainer.json file — I thought that file was supposed to be used for per-project settings, e.g. setting up dependencies needed for the project, not for per-machine settings (as this is a shared file for all contributors?). All very strange. Dev containers were advertised to me as a way to make things easier, but instead it's been the total opposite. If anyone is interested in configuration for VS Code Flatpak app, I've also made the following changes successfully using Flatseal:
All seems to work now, finally... Until I run into the next problem. But I really am not happy with machine-specific tweaks to the devcontainer.json file. That might be fine for my own projects, but what about when I want to contribute to someone else's project? |
Check this for a clean workaround that is compatible with others project. |
Thanks! Moving the |
Environment
Steps to Reproduce:
You can see the same problem in the normal GUI interface but it is less obvious what is going on. You also have the same issue if you use a custom container and (probably) any other container.
Basically, as far as I can tell, the bind mount of the user's devel dir into
/workspacesis not using thezorZflag that let's it work well with SELinux. I think this will be particularly a problem as you can't set that flag using the new--mountoption (see: Differences between “--mount” and “--volume” on https://docs.docker.com/engine/reference/commandline/service_create/#add-bind-mounts-or-volumes) at all.There is a workaround that I note here for anyone running into this issue but probably not something the tool should do automatically. You can chcon your devel directory to be modifiable by docker. For example:
chcon -Rt svirt_sandbox_file_t /full/path/to/your/codethen reattach your devel dir to the container (probably using rebuild).The text was updated successfully, but these errors were encountered: