-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Assign the file system when calling function #563
Comments
oh yeah, this sounds reasonable to me and should be possible. Assigning @codefromthecrypt as this is an API-related thing! |
@knqyf263 would context-based configuration work for you? This feels like the solution here, or at least a workaround. Something like https://pkg.go.dev/github.com/tetratelabs/wazero/experimental#Sys |
Do you mean you will add a new function to the |
I was thinking another key, actually experimental.FSKey * What would happen is that any call in the stack would have this as its FS, unless overridden again. Ex. wasm would see this FS, so would any host function call, recursively, unless some host function overrode the key again. fn.Call(context.WithValue(ctx, experimental.FSKey{}, os.DirFS(path)), ....)
|
oh.. (sorry jet lag) @knqyf263 are you also asking to have host functions read the FS? Maybe you can clarify what you need from this below:
|
ps overriding the FS entirely (similar to how it would be done in moduleconfig) is probably easier impl, though we'd have to add a security disclaimer anyway (as some WASI marketing says things like pre-open eg your code can't change the file policy after instantiation). Another way is to allow a filter, which would be easier. Ex, if downstream are a subset of the initial files, that's safer to write. Impl notes: internals are a bit awkward to re-expose as an FS due to how they are deconstructed during initialization, and that files can be currently open by the time you get to a host function call. This will get a little more interesting when we support an interface that can open files. https://github.com/tetratelabs/wazero/blob/ab25a84b4f4894384a78fc92560ae96dedd96122/internal/integration_test/fs/fs_test.go |
I just need only No. 2 for now. |
ok I will make an experimental FSKey (not WorkDirFSKey), and refer to the godoc on ModuleConfig.WithFS This will shadow any existing open files and whatnot.. I suspect we'll need to return a Close function of sorts, so that it can be cleaned up after the function call (similar to how a CancelContext works) |
well it might not be me personally, I might try to talk @anuraaga into doing this as I'm readying a talk for Gluecon :D |
If you are busy, I can work on it if you guide me. |
After taking a quick look, I guess this Line 1220 in b50bb93
And I'm considering how we should populate |
that's great! So SysContext has a few FS related functions in it. I think this needs to be extracted into a new type including a closer. Ex FsContext or something, but the name isn't terribly important as it is internal anyway. SysContext.Close should dispatch to SysContext.FS Close Ex. add FsContext to internal/wasm/fs.go which extracts the FS related functions of SysContext including its necessary new and Close parts. Then, we need to change the wasi impl to use that type instead of SysContext directly. Ex. instead of
The next step would be then making an overlay using the context. there a few parts to this:
Of course unit tests, but docs really only needed on the public type. Hope this sketch helps |
@codefromthecrypt I opened a draft PR. I will add tests, but before that, I want to make sure I'm in the right direction. Could you take a quick look when you have time? |
Fixes #563 Signed-off-by: knqyf263 <[email protected]> Co-authored-by: Adrian Cole <[email protected]>
#922 will remove this feature because it was only used once. @mathetake found another way to do it here aquasecurity/trivy#3299 |
I'd like to pass the different filesystem when calling a function as below.
This is because we want wasm to be able to access only files under
appA
andappB
. As far as I know, it is not supported now. It would be like the following in wazero.Is this the best way? I am afraid of the penalty of initializing the module every time since it is called frequently.
The text was updated successfully, but these errors were encountered: