how are preopened fds numbered?

[wanderer]

I'm confused on how preopened fds are numbered. The API doc currently says

As in POSIX, three file descriptor numbers are provided to instances on startup -- 0, 1, and 2, (a.k.a. STDIN_FILENO, STDOUT_FILENO, and STDERR_FILENO).

Other than these, WASI implementations are not required to allocate new file descriptors in ascending order.

So how do programs find the preopened fds? Wasmtime currently seems to monotonically increment the fds. Should this be considered part of the spec?

[dumblob]

So how do programs find the preopened fds? Wasmtime currently seems to monotonically increment the fds. Should this be considered part of the spec?

Should it be allowed (for security reasons) for an application to find out which fds were opened by other applications or just those fds opened by the asking application itself?

[sunfishcode]

Currently they are numbered sequentially starting at 3. And currently WASI libc depends on this, in order to be able to discover the preopened capabilities. So yes, as long as this is how it works, we should add this to the spec and document it :-).

@dumblob Currently, in Wasmtime's implementation, the wasm application fd index space is distinct from the host process' fd index space, so applications can't observe which fds are opened by other things in the same process.

[sunfishcode]

I've added some basic documentation for the pre-opened file descriptors here: bytecodealliance/wasmtime#100

(I'm working on migrating the docs into the WASI repo, but for now this is where things are.)

[rylev]

@sunfishcode Should we close this as resolved?

[sunfishcode]

Yes, the original question here has been answered!