Implement the setns syscall
task, however ready to go through other task options though. If it's not too late, I would like to discuss project specifications.
go
branch, the repo will be go toolchain compatible and thus should work with gopls. However, contributions need to be on the master branch, so it is probably not a friendly workflow to try to develop on the go branch and then migrate changes to master.
go
branch is not ideal. Online sources works but I like LSP features like find references
bazel build //:gopath
, which will create a GOPATH-style tree in bazel-bin/gopath
made of symlinks back to the original files. If you point gopls at that, it may work OK?
Read
from pkg/sentry/syscalls/linux/linux64.go
but I can't jump to AccountReadSyscall
neither
Hi, I'm considering using gVisor with Docker on AWS ECS for sandboxing third-party tools (ImageMagick, ffmpeg, etc.) to process untrusted user media. To protect the sandbox from accessing the private network access, I would like to disable networking with --network none
. To not start a new container on each tool execution and improve performance, there is an idea of running the sandbox sidecar container permanently with a tiny RPC service that exposes API to run commands in sandbox. The only IPC mechanism to communicate with a process in a gVisor container I can think about in this case is a unix socket shared from the app container/host. It will allow establishing connections from the sandbox to the host but I need the opposite direction (send RPC requests to sandbox). It sounds like I need some sort of reverse tunnelling through the unix socket. And I even managed to run a PoC with socat:
// App container: requests to 127.0.0.1:9042 proxied to 127.0.0.1:8042 in sandbox
socat UNIX-LISTEN:/share/sandbox.sock TCP4-LISTEN:9042,reuseaddr,fork
// Sandbox sidecar: tiny RPC is running on 127.0.0.1:8042
socat UNIX-CONNECT:/share/sandbox.sock TCP4:127.0.0.1:8042
However this only works one request at a time. When I start sending a few requests per second, they start to hang. It seems that socat does not properly multiplex multiple streams through a single connection.
Am I doing it wrong or missing something, are there any other IPC mechanisms to communicate with gVisor sandboxes except networking?
@hbhasker Ah yeah, the server in a sandbox can listen on a Unix socket directly but the problem is that I couldn't manage to share a sandbox internal unix socket with another non-sandbox container or host through a shared volume. I thought this is a limitation of the overlay fs.
I've found a message from @prattmic above
@TomasTurina do you want to bind sandbox-internal UDS, or host UDS accessible from outside the sandbox?
The former is definitely possible on internal tmpfs, and I thought we had a overlay to allow this on other filesystems, but that may not be enabled by default.
The latter we don't allow to help reduce attack surface on the host. With--fsgofer-host-uds
, we do allow connecting to a host UDS, which you could set up from outside the sandbox. See gvisor.dev/issue/235
@prattmic should a sandbox-internal UDS socket bound on a shared data volume be accessible from outside the sandbox? I tested that with netcat with no luck (the listening part in the sandbox does not respond to connections). Is there any workaround for that?
Sandbox container:
docker run -it --runtime=runsc --rm -v sandbox-share:/share ubuntu bash
nc -U -l /share/sandbox.sock
Regular container:
docker run -it --rm -v sandbox-share:/share --network none ubuntu bash
root@888dd3208b8f:/# ls -la /share/
drwxrwxrwx 2 root root 26 Apr 19 02:10 .
drwxr-xr-x 1 root root 19 Apr 19 02:10 ..
-r-------- 1 root root 0 Apr 19 02:10 sandbox.sock <-------- NOTE: There is no 's' bit telling this is a Unix domain socket
root@888dd3208b8f:/# nc -U /share/sandbox.sock
nc: unix connect failed: Connection refused
nc: /share/sandbox.sock: Connection refused
When the sandbox container is launched like a normal container without --runtime=runsc
the shared /share/sandbox.sock
outside the sandbox looks differently, note there is s
bit
root@32e9777384d6:/# ls -l /share/
srwxr-xr-x 1 root root 0 Apr 19 02:12 sandbox.sock