Hello folks,
I am working on a POC of a system (wasmtime backed GitHub actions) that involves downloading files and setting them up on the host.
The idea is to have a wasmtime(or Spin) based runtime that runs wasm guest components as CLI commands, which perform some of the GitHub action steps. e.g., fetching token from Vault/Tailscale, downloading tools, etc. The advantage is that we can statically define (and audit) the permissions (e.g., outbound hosts, filesystem paths, etc) GitHub actions have, which helps to make them secure.
While implementing the POC, I was able to download the file, but I couldn't find a function to change that to executable in wasip2. Is that something considered and rejected or something we can discuss and see the viability of adding it to the filesystem WIT in a future release?
(Also happy to discuss if folks think this is a bad idea).
Execute permissions aren't universal, e.g. Windows doesn't have an exact equivalent afaik
in that case maybe we can just ignore this for windows, and implement for other platform which support it? what would be the right way to collect feedback on such a proposal?
I think that might be somewhat at odds with the design philosophy of wasi-filesystem, though @Dan Gohman would be the one to speak to that. In the near term I would suggest adding your own host import, which could be relatively high-level like make-executable
.
What would be the point of being able to make a file executable from wasi considering that wasi doesn't allow spawning subprocesses anyway?
@bjorn3 presumably this would be one step in a CI pipeline where later steps wouldn't (necessarily) use WASI
yeah, the use case is to implement secure CI actions, where author of actions specify required permissions, and the runtime enforces those permissions. With that we can have the required permissions more visible and auditable.
Rajat Jindal has marked this topic as resolved.
Last updated: Nov 22 2024 at 17:03 UTC