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.
3 replies
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?
5 replies
1 reply
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.sockRegular 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 refusedWhen 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