# Bug report WASI has a capability-based security concept. A process must have a valid handle to open a resource. For example WASI runtimes let processes only open files that are inside a directory tree for which the process owns a file descriptor. wasmtime implements this with [openat2(2)](https://man7.org/linux/man-pages/man2/openat2.2.html) with flags `RESOLVE_NO_MAGICLINKS | RESOLVE_BENEATH`. Any attempt to open a file outside results in `OSError: [Errno 76] Capabilities insufficient` (`ENOTCAPABLE` / `__WASI_ERRNO_NOTCAPABLE`). `getpath.py` runs into the capability issue in several places when the module attempts to read from landmark files `VENV_LANDMARK` and `BUILDDIR_TXT`. On wasmtime the WASI process starts with CWD=`/` (root). By default the process does not have capability to access `/`. Our tests currently work around the problem by mapping on the host `SRCDIR` to `/` inside the WASI environment. Without the mapping, Python startup fails with ``` Exception ignored error evaluating path: Traceback (most recent call last): File "<frozen getpath>", line 353, in <module> OSError: [Errno 76] Capabilities insufficient Fatal Python error: error evaluating path Python runtime state: core initialized ``` # Your environment `wasm32-wasi` # Fix proposal - expose `ENOTCAPABLE` in `errno` module - map `ENOTCAPABLE` to `PermissionError`. Insufficient capabilities is a sort of permission problem. - catch `PermissionError` additionally to `FileNotFoundError` at places that read `VENV_LANDMARK` and `BUILDDIR_TXT`