At two places in the documentation there are warnings about using WASI builder inheritSystem():
|
The experimental CLI uses `inheritSystem()` by default, granting the Wasm module full access to the host filesystem, environment, and stdio. Do not use it with untrusted modules in its current form. |
|
**Never use `inheritSystem()` with untrusted modules** — it grants full host filesystem, environment, and stdio access. |
However, inheritSystem() only seems to inherit stdout, stderr and stdin but not the filesystem or environment variables:
|
public Builder inheritSystem() { |
|
this.stdout = System.out; |
|
this.stdin = System.in; |
|
this.stderr = System.err; |
|
return this; |
|
} |
Or am I overlooking something? Could be the case of course that the CLI additionally provides access to the host file system, but that is unrelated to inheritSystem() then?
(As side note: It would also be good if inheritSystem() and also other parts of the API had Javadoc to make it clearer what they do and how to use them. But I guess that might be a bigger project.)
At two places in the documentation there are warnings about using WASI builder
inheritSystem():endive/docs/docs/experimental/cli.md
Line 9 in 7505798
endive/docs/docs/security/best-practices.md
Line 57 in 7505798
However,
inheritSystem()only seems to inherit stdout, stderr and stdin but not the filesystem or environment variables:endive/wasi/src/main/java/run/endive/wasi/WasiOptions.java
Lines 170 to 175 in 7505798
Or am I overlooking something? Could be the case of course that the CLI additionally provides access to the host file system, but that is unrelated to
inheritSystem()then?(As side note: It would also be good if
inheritSystem()and also other parts of the API had Javadoc to make it clearer what they do and how to use them. But I guess that might be a bigger project.)