Stream: git-wasmtime

Topic: wasmtime / issue #9095 export func authentication

Wasmtime GitHub notifications bot (Aug 09 2024 at 15:08):

itachaaa opened issue #9095:

When the WASM plug-in calls back the host, is there a way to know which WASM plug-in is on the host side, so as to authenticate different WASM plug-ins, to ensure that the interface exposed by the host does not have the problem of permission leakage.

Wasmtime GitHub notifications bot (Aug 09 2024 at 18:40):

alexcrichton commented on issue #9095:

For this it's recommended to store state in the T of Store<T>. Does that work for you?

Wasmtime GitHub notifications bot (Aug 10 2024 at 02:46):

itachaaa commented on issue #9095:

For this it's recommended to store state in the T of Store<T>. Does that work for you? 重试    错误原因

We've tried that too, and it probably won't solve the problem. Because T is shared in the store, different instances in the same store may tamper with this T to bypass our authentication rules.
I'm curious if there's a way to automatically bring up the module name interface or capability when calling back the host method.

Wasmtime GitHub notifications bot (Aug 11 2024 at 21:02):

nerdachse commented on issue #9095:

For this it's recommended to store state in the T of Store<T>. Does that work for you?

Could you elaborate a bit on this please?

I don't see right now how that data could be relied on and have a very, very similar "problem"/question to the Op

Wasmtime GitHub notifications bot (Aug 12 2024 at 16:19):

alexcrichton commented on issue #9095:

I'm not really sure what "authentication" means in this context. My answer of using T is derived from the fact that as the embedder you're in control of what gets added to a Linker. In that sense I'm not sure how to authenticate one call over another because I would imagine that you could customize one closure being added vs another. Each closure could access some part of T and your own embedding could ensure that what's accessed is all disjoint.

Basically what I'm saying is that the customization doesn't happen when the function is called, it happens when the function is defined. Whatever adds a function to the linker would customize what the host function does by accessing necessary parts of T, perhaps only passing a smaller borrow to disallow access to the whole state.

Otherwise in terms of authentication I would need more of an example of what you're trying to achieve as it's not clear to me.

Wasmtime GitHub notifications bot (Aug 15 2024 at 07:36):

itachaaa closed issue #9095:

When the WASM plug-in calls back the host, is there a way to know which WASM plug-in is on the host side, so as to authenticate different WASM plug-ins, to ensure that the interface exposed by the host does not have the problem of permission leakage.

Last updated: Oct 23 2024 at 20:03 UTC