Consider support wasi file read ABI

[bianpengyuan]

The wasi abi for file read is already defined, but not implemented. This will be really useful for the case where a secret needs to be read from a file:

proxy-wasm-cpp-host/src/exports.cc

Line 729 in b7d3d13

Word wasi_unstable_fd_read(void *, Word, Word, Word, Word) {

[mathetake]

FYI, we could read secret emebedded in env vars once #126 and envoyproxy/envoy#15009 are merged, though reading file functionality could also be helpful for users.

[mathetake]

@PiotrSikora thoughts?

[bianpengyuan]

FYI, we could read secret emebedded in env vars once #126 and envoyproxy/envoy#15009 are merged, though reading file functionality could also be helpful for users.

I think normally people would mount secret with file, instead of specifying via env var, which is not secure enough.

[PiotrSikora]

We have people asking about this, and while some of the use cases are better served using existing facilities (e.g. reading plugin configuration from Envoy instead of from local file), some are a bit more reasonable (e.g. reading multi-megabyte files to initialize complex libraries, which we don't necessary want to propagate through the xDS pipeline).

I believe that ultimately this will be a footgun (e.g. used for serving static files directly from Wasm), but it seems that we have to add it to unblock some legitimate use cases.

WASI has a concept of pre-opened directories (with read & write access to files within that directiory), but I think we need to be even more strict and allow only read access to pre-opened files. I have an early prototype doing just that.

One issue with that approach is that WASI assumes stable sandbox (i.e. args, envs, and preopen dirs are all initialized at WasmVM startup), which means that we need to configure sandbox on a per-WasmVM and not a per-plugin basis.

[linzg2002]

@PiotrSikora, any update for this new feature? In my project, I want to create an envoy_fitler with WASM to do the authenticatoin&authorization check in the istio side car. To fulfill that, the filter needs to read many permission configuration data from filesystem. So very like to see the feature would be implemented(read only is fine). Anyother alternative approach is also welcomed. Thanks.