Repository navigation
Directory listings should include preopens #414
Description
Activity
Its sounds like you are asking for some kind of virtual root directory to be created by wasi-libc... and in the case where
/is actually included in the pre-opens that would then need to be somehow overlaid on top of the pre-opened root?That sounds like fair amount of extra complexity. I wonder if there is some way to specify more precisely the expected host behaviour to avoid this kind of inconsistency?
I'm not sure I have a strong opinion here but others might (cc: @sunfishcode, @pchickey). My bias would be towards simplicity, though. @SteveSandersonMS, the opinion I do have is that whatever we decide, we should encode the behavior in a test over at the wasi-testsuite.
From a capabilities perspective, it's a a little closer to the spirit of capabilities to not make these paths appear in
readdir. Programs should ideally be given paths of things they should open, rather than open-world exploring the filesystem to discover all of the things that exist with it. So I propose thatreaddirshould not implicitly include preopen directories.That said, I agree that wasi-libc could implement this on its own, and that some users would find useful. Right now, wasi-libc's preopen lookup mechanism is very simple. If we added a full VFS tree to wasi-libc, it'd add some amount of complexity and code size that not everyone needs.
So I propose that this be approached as a wasi-libc feature, which is built in a way that makes it optional, so that users can chose whether to use the simple small implementation or the larger full-tree implementation.
Reacted by gureguI think WebAssembly/WASI#742 is a more elegant long-term solution to this. You would get the VFS tree for free, and it conceals unnecessary information from the guest (which directories are preopens and which are real files under preopens), which I think is generally a good thing. I think the default model of having preopens as siloed namespaces is needlessly unintuitive.
Transferred from bytecodealliance/wasmtime#6396
wasi-libc's behavior (and hence Wasmtime's behavior) for directory listings (via the WASI
fd_readdirAPI?) 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: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").
After discussion at bytecodealliance/wasmtime#6396 with @bjorn3, it sounds like:
/a/b/centails also simulating that/a/bexists and containsc, etc, otherwise filesystem invariants are broken.