gvisor: Cannot read mounts in rootless Podman
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:
$ runsc -debug -network none -rootless do echo ok
Error reading mounts file: error unmarshaling mounts: unexpected end of JSON input
JSON bytes:
creating container: cannot create sandbox: cannot read client sync file: waiting for sandbox to start: EOF
In a regular Docker (not rootless) container, this command works:
$ runsc -debug -network none -rootless do echo ok
ok
Steps to reproduce
- Install Podman in your system.
- Execute into an Alpine container with
podman run -it --rm alpine:edge ash
- Install
runsc
based on the installation instructions - Run
runsc -debug -network none -rootless do echo ok
runsc version
runsc version release-20221107.0
spec: 1.0.2-dev
docker version (if using docker)
$ podman --version
podman version 4.3.1
uname
Linux 6.0.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 10 Nov 2022 21:14:24 +0000 x86_64 GNU/Linux
kubectl (if using Kubernetes)
No response
repo state (if built from source)
No response
runsc debug logs (if available)
Error reading mounts file: error unmarshaling mounts: unexpected end of JSON input
JSON bytes:
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 2
- Comments: 17
Commits related to this issue
- gofer: don't create bind-mounts in /proc/self selinux doesn't allow to do that. Fixes #8205 PiperOrigin-RevId: 588891222 — committed to google/gvisor by avagin 7 months ago
I think this issue was fixed by https://github.com/google/gvisor/commit/c6a1db5baec7616983b14ac06e84bee45330a9d3. Can you please confirm?
I see that the relevant check in Gofer happens here:
https://github.com/google/gvisor/blob/d8aa09e04c4e38155dfcee6ed0495c2b29f604fc/runsc/cmd/gofer.go#L418
Since we are already running in rootless Podman, we may opt to reuse the existing
/proc
and/
paths. My understanding is that this can happen via the-TESTONLY-unsafe-nonroot
flag, and it works indeed: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?