Cheers!
I am the author of an Elixir package to execute WASM/WASI. It is currently based on wasmer, but I'm working on a port to wasmtime. It's working great so far, I'm just missing one feature: I wish to preopen directories for WASI with custom capabilities. As far as I know, the WasiCtxBuilder currently assumes that any preopened directory gets all dir/file capabilities. However, I want to be able to specify that e.g. a directory is read-only.
The change needed to implement this seems to be quite small as the fundamentals are in place already. (see https://github.com/tessi/wasmtime/commit/c45b3d2e299f62e06aa4b5facc9c68b860ff55fb). I would very much love to contribute my patch back to mainline wasmtime. Is there interest in this feature? Or should I solve this some other way instead - maybe I missed some obvious feature? If there is interest, is it just opening a PR and writing some tests or is there more to take care of?
:+1: we would use this where currently we're mutating the WasiCtx
after building it
Wasi is removing the rights system entirely. See https://github.com/bytecodealliance/wasmtime/pull/4666 and https://github.com/WebAssembly/wasi-libc/pull/294. In any case I believe you can inline the definition of push_preopened_dir
and change the DirCaps
.
bjorn3 said:
In any case I believe you can inline the definition of
push_preopened_dir
and change theDirCaps
.
Not exactly; it uses DirEntry
which is a private struct. You can get the same effect with WasiCtx::insert_dir
but it requires understanding more of the preopened dir internals.
Right
Is anyone working on a wasi vfs that could be used to emulate capabilities?
No clue
I am working in this space, but am in a meeting at the moment
thanks a ton for your input :heart:️. I'm curious on the WASI fs capability story. Will have a look at the provided links and hints once I put my daughter to bed
Hi! So, readonly directories is definitely something we want to support. The "rights" system could in theory be used to do that, but it's a very complex and obscure system that makes many use cases more complex without adding value. It rarely gets used for anything other than setting up readonly directories. So at the WASI standards level, the next version of WASI has removed the "rights" system, with the idea that implementations, such as Wasmtime, can add their own flags to mark directories as readonly.
hmm, this probably means I have to accept that all preopened dirs are open for the moment. Since any potential change I could implement by manipulating todays DirCaps or FileCaps would be removed soon, right? :thinking: I rather introduce a breaking change to my users now (wasmer supports read/write/create flags - I have to drop that support without replacement) than having two breaking changes in quick succession (use some obscure DirCaps/FileCaps workaround now, do the real thing later).
Even if it's not the news I want to hear, I'm really glad for all your swift and nice answers. It prevented me from sinking time into a solution that would be abandoned. Thanks!
Is there a place/page/blog/repo I could follow for updates on wasmtimes FS story?
tessi has marked this topic as resolved.
@tessi this was only recently mentioned in the WASI subgroup meeting for what is in scope for wasi-preview-2. For wasmtime-fs story, it's bundled in with work for wasi preview 2. The best place to track that work is this project tracker. The issue to follow for wasmtime fs support is #4273
With all of that said, I don't think we'll have an answer for what you're looking for in the short-term.
Thanks a ton Bailey! This really helps me out following the news :)
Last updated: Nov 22 2024 at 16:03 UTC