Directory listings don't include preopens
Closed this issue · 8 comments
Wasmtime's behavior for directory listings (via the WASI fd_readdir API?) is surprising and is inconsistent with Wasmer.
If there is a preopen for /blah, do you expect a directory listing for / to include /blah? Most people would do, because that's how all normal filesystems work. However:
- This is not the case with wasmtime. Each directory listing returns only the files that literally exist on the host within that directory, ignoring any other preopens that may be mapped into the guest directory.
- But it is the case with wasmer - it correctly includes other preopens that have been mapped to the guest directory.
Repro code: https://gist.github.com/SteveSandersonMS/ff5f5cb91524bbcde24a168841e66f10
Existing application code could be broken in strange ways if typical filesystem invariants are not maintained (e.g., "a directory's parent always contains that directory").
Should this be considered a WASI spec defect, since it does not seem to define any rules around this? Or would people agree the desired semantics are obvious (i.e., should behave like normal filesystems) and that it should be counted as a Wasmtime bug?
I think if anything should do this remapping it should be wasi-libc, not the host wasi impl. If I close the preopen at /blah I did expect it to become impossible to access anything under this preopen that I haven't already opened. Being able to do open("/blah/foo") instead of having to do openat(<<blah>>, "foo") is a mechanism inside of wasi-libc for compatibility with existing code. A program designed for wasi that only uses openat shouldn't see anything of this back compat mechanism IMHO. Also what if there is no preopen at /? There is nothing to add the extra dir entries too, so only wasi-libc can provide the illusion like there is a blah dir in /.
Being able to do
open("/blah/foo")instead of having to doopenat(<<blah>>, "foo")is a mechanism inside of wasi-libc for compatibility with existing code.
That makes sense. But if the goal is compatibility, it also makes sense to complete this picture and simulate the existence of ancestor directories containing the preopens (whether that's done by wasmtime or wasi-libc).
Yeah, I think it should be done in wasi-libc.
Thanks @bjorn3. I've filed WebAssembly/wasi-libc#414
Should we close this issue then?
I agree that this ought to be to be solved in wasi-libc, rather than in the host, so I am in favor of closing this. If for whatever reason the wasi-libc decision is that this needs to be implemented in hosts, then we'll want to update the spec text and tests to note that and we'll open a new issue to implement the spec correctly.
I agree; let's discuss this in the wasi-libc issue, and see where it goes from there.
Sounds good. Thanks everyone!