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 withopenat2(2) with flagsRESOLVE_NO_MAGICLINKS | RESOLVE_BENEATH. Any attempt to open a file outside results inOSError: [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 filesVENV_LANDMARK andBUILDDIR_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 hostSRCDIR 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 insufficientFatal Python error: error evaluating pathPython runtime state: core initialized

Your environment

wasm32-wasi

Fix proposal

• exposeENOTCAPABLE inerrno module
• mapENOTCAPABLE toPermissionError. Insufficient capabilities is a sort of permission problem.
• catchPermissionError additionally toFileNotFoundError at places that readVENV_LANDMARK andBUILDDIR_TXT