containerd / containerd/runwasi

Pre-open directories and other capabilities

Open
#266 3 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Rust
Stars
1.3k
Forks
131
PR merge metrics
No merged PRs in 30d

Description

In this [Slack conversation](https://cloud-native.slack.com/archives/C04LTPB6Z0V/p1692799401937929) and #265, we have started to discuss the fact that we are pre-opening the container root filesystem (fs) to the Wasm guest application. Pre-opening the root fs for use by the guest Wasm app is intended to enable users to build Wasm apps that feel more like the apps they know and love running in containers.

The default for many Wasm runtimes is to offer the guest no capabilities. This least privileged approach is one of the key features of Wasm.

We may want to reconsider pre-opening the container root fs in the future. Perhaps, we can replace the default behavior with a user specified behavior, opt'ing in to the pre-open. Additionally, we may also want to consider how other capabilities could be expressed by the user.

Contributor guide

Open the contributing guide

Research direction

Read issue #265 and the linked Slack conversation first; no file, test, or entry point is named here. Clarify whether pre-opening the container root filesystem should become opt-in and how users should express other capabilities, then document an agreed scope before implementation.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, wasm
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.