kubkon opened Issue #2891:
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.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.
Is that intended behaviour or a bug, or most likely, have I misunderstood something?
pchickey commented on Issue #2891:
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 commented on Issue #2891:
The issue to remove the rights concept is https://github.com/WebAssembly/wasi-filesystem/issues/31, and I've now submitted https://github.com/WebAssembly/wasi-filesystem/pull/32 to implement it.
kubkon commented on Issue #2891:
Ah, gotcha, thanks @pchickey and @sunfishcode!
kubkon commented on Issue #2891:
Oh, since the issue was more to get up-to-speed with the development, I guess I'll just close it.
kubkon closed Issue #2891:
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.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.
Is that intended behaviour or a bug, or most likely, have I misunderstood something?
Last updated: Dec 23 2024 at 12:05 UTC