wasi: should fd_readdir capability be cascaded down now?

[kubkon]

I've recently tried bumping Zig's wasmtime dependency from v0.20 to v0.26, and noticed that since v0.23, the behaviour of fd_readdir capability has changed:

v0.22.1:

It was OK to create a subdir, and then open it with for iteration with fd_readdir cap even if the dir level above was opened without this cap.

Trace

v0.26:

It seems that the entire dir chain (excluding preopens of course) now requires fd_readdir right in their base rights to be able to iterate on some nested subdir.

Trace

---

Is that intended behaviour or a bug, or most likely, have I misunderstood something?

[pchickey]

Yes, we ended up changing a handful of things around how the rights system works in #2487. The new behavior is the intended behavior, at least for now. The intended behavior of the rights system was never written down, and varies widely between implementations, so its hard to say exactly what the right thing to do here is - only allowing base rights always be a subset of those inherited seemed like a reasonable design choice, though.

FWIW, our current thinking is that the rights system doesn't actually do very much for wasi's filesystem and we should get rid of it in favor of a pair of bits for read & write permission, and let any finer-grained access control be implemented by virtualization of the filesystem interface, which will be possible (in pure wasm) one day soon. We're waiting on virtualization to be possible via the new-abi work upstream in the standards repo before tearing out the rights system completely.

[sunfishcode]

The issue to remove the rights concept is WebAssembly/wasi-filesystem#31, and I've now submitted WebAssembly/wasi-filesystem#32 to implement it.

[kubkon]

Ah, gotcha, thanks @pchickey and @sunfishcode!

[kubkon]

Oh, since the issue was more to get up-to-speed with the development, I guess I'll just close it.