If I wish to change a component's access at runtime, is it okay to switch out it's WasiCtx after the instance is created?
For example, if I want to give it access to another folder on the host.
That should be fine yeah, and while the methods don't currently exist I think it would make sense to additionally add methods to WasiCtx
to do this on-the-fly so you don't have to create a whole new context
Or at least make WasiCtx
cloneable
although I guess that doesn't matter is you can't change the state without the builder.
Cloning might be a bit tougher since it can contain things like closures, but yeah mutation should be relatively easy to add
Depends on what you mean by "change" access. Mutating the WasiCtx (or swapping it out entirely) might work for new resources, but it won't automatically revoke access to already-opened resources.
That was the idea.
Also, multiple properties are expected to never change during the lifetime of a component instance. Such as: filesystem preopens, insecure-seed
Can you point me to a reference please?
Sorry, I updated my previous answer at the same time as your question. See previous comment
Some mor eexamples: wasi-cli -> get-environment, get-arguments, initial-cwd
Mutating the WasiCtx might work for new resources, but it won't automatically revoke access to already-opened resources.
And at the same time, updating socket_addr_check
& allowed_network_uses
would immediately apply to both the old _and_ new sockets.
So thinking about it more, I would be very careful about mutating any property on an WasiCtx that is already in use. I see issues ranging from "subtly wrong" to straight up TOCTOU security vulnerabilities.
Is there a current best practice for managing guest permissions at runtime then or would this currently require unloading and reloading the component?
Do you have any specific permissions in mind?
Dynamically granting component extensions access to file's on the host is the current use case I'm considering.
Do you have a custom contract between your host application and the extensions? Because, while the WASI preopens should remain static, you may be able to expose your own method that opens files dynamically
Yes, I'm working on a plugin system, so I"m in control of the API
Last updated: Nov 22 2024 at 16:03 UTC