العمل مع نظام ملفات WASI

A WASM module has no ambient authority — it cannot open any file by default. WASI grants file access only through preopened directories handed to the module at startup.

• No path traversal outside what was granted
• Access is capability-based, not permission-based

When a runtime launches a module it can map a host folder to a guest path. The module receives a file descriptor for each mapping.

Example with wasmtime: wasmtime --dir=. app.wasm grants the current directory.

In a WASI language SDK the standard library file APIs are wired to WASI calls. In C, fopen works only for preopened paths.

Writing also requires a preopened directory with the right rights. Attempting to write outside it returns an error such as ENOTCAPABLE.

Each WASI file descriptor carries a set of rights (read, write, seek, etc.). A directory descriptor can be more restrictive than its host counterpart, enabling least-privilege design.

WASI resolves paths relative to a preopened descriptor. The runtime picks the longest matching preopen. There is no global root; / is meaningless unless mapped.

Languages like C compiled with wasi-sdk use wasi-libc, which translates POSIX calls into WASI syscalls. This is why familiar APIs just work inside the sandbox.

Directory iteration uses fd_readdir under the hood. High-level languages expose this as normal directory listing once a directory is preopened.

Typical filesystem errors when learning WASI:

• ENOENT — file not found within the preopen
• ENOTCAPABLE — path is outside any granted directory
• EACCES — descriptor lacks the required right

You can grant several directories, each with a distinct guest alias.

Grant the narrowest directory possible, prefer read-only preopens, and never assume host absolute paths exist inside the module.

You learned that WASI uses preopened directories and capability-based descriptors to expose files safely. Paths resolve relative to preopens, rights enforce least privilege, and wasi-libc bridges POSIX APIs to WASI syscalls.