Skip to content
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

Options to pass env vars from OCI Spec to WASI Context #2815

Closed
Mossaka opened this issue Jun 12, 2024 · 6 comments · Fixed by #2820
Closed

Options to pass env vars from OCI Spec to WASI Context #2815

Mossaka opened this issue Jun 12, 2024 · 6 comments · Fixed by #2820
Assignees

Comments

@Mossaka
Copy link
Contributor

Mossaka commented Jun 12, 2024

Wasm containers are different from Linux containers in many ways, one of them being their handling of environment variables. A Wasm runtime, by default, does not grant any environment variables to Wasm modules unless explicitly passed to the WASI Context (e.g., using wasmtime's API). This contrasts with Linux containers, which can utilize all the environment variables available to them.

Given this difference, it seems unnecessary for libcontainer to modify the main process's environment variables before fork-exec container processes (as seen here) in Wasm use cases. Moreover, mutating environment variables before calling Executor::exec complicates the delineation between the Containerd shim and Wasm containers (see more in this issue from runwasi). The runwasi shim sets up the Wasm runtime (e.g., Spin, Wasmtime, WasmEdge, etc.) within the container namespace, but this setup is not part of the user's Wasm container code. Runwasi introduces a third layer, the Wasm runtime, between the traditional shim and Linux container layers.

We propose that container environment variables, such as those from the PodSpec in Kubernetes, should be directly passed to the WASI Context instead of the shim process, which is still configuring the Wasm runtime.

I am not sure how exactly we can achieve this, but I have shared some ideas in this issue. I welcome your thoughts on this matter.

@utam0k utam0k self-assigned this Jun 13, 2024
@Mossaka
Copy link
Contributor Author

Mossaka commented Jun 13, 2024

It would be nice for libcontainer to provide an API to the Executor to set the environment variables.

Linux executor -> remains the same
Wasm executor -> environment variables should be passed to the execute and down to Wasm runtime's initialziation of the WASI context.

@utam0k
Copy link
Member

utam0k commented Jun 15, 2024

Expanding Executor makes sense to me. But most cases are enough to clear the host's environments, aren't they? So, why don't we expand a new method in Executor related to handling environments for special cases, such as Wasm, and implement the default behavior to clear all ends on the host in the new method we expand?
https://doc.rust-lang.org/book/ch10-02-traits.html#default-implementations

@utam0k
Copy link
Member

utam0k commented Jun 15, 2024

@Mossaka If you don't mind, I'd like to make this issue a good first issue.

@utam0k
Copy link
Member

utam0k commented Jun 15, 2024

cc @musaprg

@musaprg
Copy link
Contributor

musaprg commented Jun 15, 2024

Hi, I'd love to pick this up. Let me try.

@utam0k
Copy link
Member

utam0k commented Jun 15, 2024

Sure!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants