WASI Preview 1 imports on Preview 2 component runtime permission boundary

Recommended Version Negotiation

A host should require an explicit adapter rather than implementing silent import upgrades when presenting a WASI Preview 1 module to a Preview 2 component runtime. Because Preview 1 uses a flat namespace (wasi_snapshot_preview1) and Preview 2 utilizes a resource-based Component Model (WIT), silent upgrades risk bypassing the granular capability-based security model intended for Preview 2.

The Logic for Explicit Adapters

The transition from Preview 1 to Preview 2 is not a simple version bump but a paradigm shift from syscall-style imports to interface-based capabilities. An explicit adapter serves as a translation layer that maps legacy flat imports to the new resource handles. This ensures that the host can enforce permission boundaries at the component interface level before the request ever reaches the guest module.

Mapping Capabilities and Permission Boundaries

To preserve the intended permission boundary, capability handles must be mapped through a shim that translates the legacy state into a Preview 2 resource. The following mapping logic is typically applied by the adapter:

• File System: Legacy fd_t integers are mapped to wasi:filesystem resource handles. The adapter must validate that the requested path is within the pre-configured virtual filesystem root granted to the component.
• Network: Preview 1's limited socket support is mapped to wasi:sockets. The boundary is enforced by the host runtime, which only provides the adapter with handles to specific allowed endpoints.
• Environment/Args: These are mapped to the wasi:cli interface, ensuring the module cannot access the host's actual environment variables unless explicitly passed through the component's WIT definition.

Verification Steps

To verify how a runtime is handling these boundaries, use the following scoped commands (assuming wasm-tools and a compatible runtime like Wasmtime):

# Inspect the component binary to see if it contains a legacy adapter or direct imports
wasm-tools component inspect module.wasm

# Test the module with explicit legacy support to compare behavior
wasmtime run --wasi-snapshot-preview1 module.wasm

Implementation Uncertainty

Current runtime behavior is fragmented. Some implementations provide a built-in compatibility shim that behaves like a silent upgrade, while others strictly adhere to the Component Model. Because the Canonical ABI does not define a standard negotiation for this specific legacy case, the security of the boundary depends entirely on the adapter's implementation of the mapping.

Diagnostic Detail Needed: To refine this recommendation, please specify the target runtime (e.g., Wasmtime, Wasmer) and whether the module is being wrapped in a .wasm component or loaded as a raw core module.