containerd / containerd/runwasi

Env of native containers is not being set

Open
#1,061 7 comments 0 reactions 0 assignees View on GitHub
Dominant language
Rust
Stars
1.3k
Forks
131
PR merge metrics
No merged PRs in 30d

Description

In a commit some time ago, it had been changed how env variables are being passed to the container: https://github.com/containerd/runwasi/commit/76f436fdd7084bc573969b16bcc03b6a27db0727
The change expects the shim implementation to set the env during run_wasi and therefore skip libcontainer DefaultExecutor.setup_envs using a no-op implementation.

This misses to handle the case of native Linux containers, where simply no env is set, because obviously, there is no responsible shim.
Environment is for example crucial when running a Linux container sidecar of a WASM container pod in Knative (queue-proxy), which fails in the current state because of the described behaviour.

A fix for this would be deciding in the LibcontainerExecutor implementation whether to skip env setup based on the container type.
To determine the container type, the OCI spec needs to be available. (https://github.com/youki-dev/youki/blob/8ce850c2bba192c5170c3c51ce1ea65c1c057231/crates/libcontainer/src/workload/mod.rs#L81)
This would require a change in the youki/libcontainer API, to provide an additional parameter in DefaultExecutor.setup_envs.
If this (breaking?) libcontainer change is considered viable, I can create a PR there.

An alternative approach without libcontainer changes would be:
- not replacing the DefaultExecutor setup_envs with a no op
- therefore enabling process env setup by default
- clearing env before executing run_wasi in exec
This commit shows how it would look like:
https://github.com/toobeeh/runwasi/commit/04f1a5b3efc93122ca80837dc511085dfc5ca881

Personally I don't think this internal fix should be preferred, since set vars -> clear vars is unnecessary overhead for the default behaviour of running a WASM container.
If it should be good enough for a hotfix/temporary workaround, I may open a PR though.
I tested the version at mentioned commit and it solves the problem I am having with knative (queue-proxy sidecar).

Contributor guide

Open the contributing guide

Research direction

Start by reading the LibcontainerExecutor environment handling around DefaultExecutor.setup_envs and the run_wasi/exec entry points, then compare the two referenced commits. Use the OCI spec and libcontainer workload/mod.rs to determine how native versus WASM containers are identified. Done means native Linux containers receive their configured environment while WASM execution retains its intended environment behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes, rust, wasm
Domain
infrastructure
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.