Hacker News Reader

Comment by mikewarot | Hacker News Reader

It's not obvious to me how you make capabilities available to the code running inside the WASM virtual environment.

The core security advantage of WASM is the fact that no file capabilities are provided to the workload by default.

It gets setup fairly similarly to how you would run a "normal" runc container. containerd passes along a path to the rootfs of the container (for wasi I'd expect to be just the wasm module) which is built from the OCI image along with a set of mounts the be mounted to the rootfs. The project here goes ahead and performs those mounts to the rootfs path and then maps that rootfs path into wasmtime's WASI config as "/".

If you have something like a Kubernetes volume, config map, secret, etc. this is all prepared by Kubelet and winds up as mounts we need to perform as mentioned above.

> Included in the repository is a PoC for running a plain wasi host (ie. no extra host functions except to support wasi system calls).

Looks like that’s not decided yet.

In theory you could use pod.spec.volumes to hand it over to the shim for the wasi preopens.[1]

Whether that’s a good idea is the other side of the story…

[1] https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

Volumes are mapped in already. They get mounted to the containers rootfs dir, and that is used as a preopen for wasi.

https://github.com/deislabs/runwasi/blob/9a43a31c1f29df65392...

Reply on news.ycombinator.com