WebAssembly / WASI

WebAssembly System Interface
Other
4.72k stars 240 forks source link

Make clear for WASI implementation #514

Closed harry900831 closed 1 year ago

harry900831 commented 1 year ago

I have some questions that need to be confirmed while using WASI and running the WebAssembly/wasi-testsuite.

Thanks in advance!

sunfishcode commented 1 year ago

Overall, WASI is not throughly documented yet. Over time we hope to write more documentation. For now, there often aren't authoritative answers to questions like this. The best we can do for now is to just consult major implementations, consult POSIX, consult wasi-testsuite, consult our own design sensibilities, and try to find the right balances, and document the answers we come up with.

  • Does the attribute of file_stat for stdin, stdout, stderr need to be all zero? Or it's implementation-defined for the runtime? Since it should be all zero to pass this test, but I didn't find any place that specifies this.

POSIX doesn't require this, and in fact, POSIX says that these should be the timestamps of whatever files are redirected to a programs' stdio streams. But from a WASI perspective, it's desirable to run untrusted WASI programs that just read from stdin and write to stdout and don't have any other information leaking in about the host environment. Zeroing out these fields instead of just leaving them to the implementation ensures that programs won't implicitly depend on some engines providing meaningful values in these fields. So I propose we keep this test and zero these fields.

  • What are the values of the fs_rights_base and fs_rights_inheriting for using wasi::fd_fdstat_get on preopen fd?

The whole "rights flags" subsystem is confusing and unhelpful in a WASI context, and so looking forward, it's been removed in preview2. I would propose that in preview1, there's no need to ever deny a fd_fdstat_get call.

  • wasi::OFLAGS_EXCL is a flag that can be used while using wasi::path_open, document said that it meansFail if file already exists. POSIX has a similar flag called O_EXCL and it is used to ensure the call creates the file when using O_CREAT which means that it is undefined without setting O_CREAT in POSIX. My question is that what is the behavior for OFLAGS_EXCL in wasi, should it fail whenever the file exists or fail only when wasi::OFLAGS_CREAT is used and the file already exists.

The intention here is that OFLAGS_EXCL should map to O_EXCL in the host on POSIX host implementations, without any extra fstat or other calls. I think that means it should only cause a failure if O_CREAT is also used.

  • Similar question above, if we use wasi::path_open to open a directory with wasi::OFLAGS_DIRECTORY and setting the right to invoke fd_write, should it raise errno isdir? Since opening a directory with write access is forbidden in POSIX and it may raise EISDIR.

Yes, that sounds right to me.

  • At last, a general question, in the document I found so far, there are a lot of unclear parts, should we treat them just like what POSIX should do since lots of parts are similar to POSIX or treat it as it literally means.

The overall intention of the API is to follow POSIX unless there's a reason not to. Sometimes there are reasons, such as Windows or other OS's having other behaviors, and we have to work out the right compromise. If you find interesting corner cases, please consider submitting issues about them, or possibly even submit tests to the wasi-testsuite repo.

harry900831 commented 1 year ago

Thanks for your reply!

sunfishcode commented 1 year ago

In preview2, the plan is for stdio streams to be actual streams, so they won't have file attributes. wasi-libc will provide POSIX compatibility by filling in values as needed. The rights subsystem has been removed. I've now filed https://github.com/WebAssembly/wasi-filesystem/issues/96 about O_EXCL. Opening a directory without the fd_write right is now clearer, as it's now a write o-flag, and I've now filed https://github.com/WebAssembly/wasi-filesystem/issues/97 to track documenting open-at's errors.