-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Cannot read mounts in rootless Podman #8205
Comments
I used the
|
I see that the relevant check in Gofer happens here: Line 418 in d8aa09e
Since we are already running in rootless Podman, we may opt to reuse the existing
Still, this is a pretty scary looking argument. Is it safe using it in a sandbox within a sandbox use case? Else, is there a better way to achieve the original goal?
|
A friendly reminder that this issue had no activity for 120 days. |
@apyrgio have you found another solution that doesn't rely on |
Unfortunately not. I haven't managed to work more in this front actually. |
I think this issue was fixed by c6a1db5. Can you please confirm? |
Doesn't look like it I'm afraid. The original invocation (
(note that the line Also, the altered invocation ( |
@apyrgio is selinux enabled? If the answer is yes, could you try to temporary disable it and reproduce the issue? $ sestatus |
selinux doesn't allow to do that. Fixes #8205 PiperOrigin-RevId: 588891222
@apyrgio @terenceli could you try out #9798? |
@avagin in my case it doesn't work. I did some analysis, the issue is happen in here: Your fix code is after it. This issue seems to be a general issue 'mount procfs from unprivileged container'. It is discussed in runc issue opencontainers/runc#1658 I used Alban's workaround in here and It works. Following is my Ubuntu test. The /mnt/proc volume is in Alban's workaround.
So my question, could we find a more elegant fix/workaround for we can use gVisor in unprivileged docker/podman environment? I rely this to build a process-level sandbox. |
You are right. I created a fedora vm to reproduce the issue, but runsc failed differently there.
Thank you for researching the problem. I think 063ee51 should fix the issue. Could you try it out? |
@avagin Yes, after apply this patch, it works! Thanks |
Oh, that's great! Thanks a lot for the progress on this front. @terenceli, just to be sure, did this fix work within a rootless Podman container, as described at the top of the issue? If not, I can give it a go as well. |
@apyrgio Sorry, I don't try it now. I have tried it in Ubuntu and docker env. You can test it in Podman. |
@apyrgio I have tried this patch using podman. With selinux set to Permissive, it works, and with selinux enabled, it doesn't work. @avagin Could you summit a PR to upstream?
|
Thanks a lot @terenceli. Unfortunately I didn't have time to test it on my own, but the results look promising! For our use case (Dangerzone) we are spinning up containers that don't have a network device, so it could very well be that nested gVisor will work, even with SELinux enabled. That's a great development! |
If the existing proc instance has over-mounted areas, it can be impossible to mount a new /proc instance (look at SB_I_USERNS_VISIBLE for more details). Actually, runsc-gofer needs /proc just to open /proc/self/fd and to read a few generic files, so it doesn't need a proc instance of the target pid namespace. Fixes google#8205
If the existing proc instance has over-mounted areas, it can be impossible to mount a new /proc instance (look at SB_I_USERNS_VISIBLE for more details). Actually, runsc-gofer needs /proc just to open /proc/self/fd and to read a few generic files, so it doesn't need a proc instance of the target pid namespace. Fixes #8205 FUTURE_COPYBARA_INTEGRATE_REVIEW=#10028 from avagin:proc-vs-unserns 805fb9b PiperOrigin-RevId: 608729405
Description
I'm trying to run gVisor within rootless Podman. The aim is to use gVisor for its syscall interception capabilities. However, I get the following error:
In a regular Docker (not rootless) container, this command works:
Steps to reproduce
podman run -it --rm alpine:edge ash
runsc
based on the installation instructionsrunsc -debug -network none -rootless do echo ok
runsc version
docker version (if using docker)
uname
kubectl (if using Kubernetes)
No response
repo state (if built from source)
No response
runsc debug logs (if available)
The text was updated successfully, but these errors were encountered: