-
Notifications
You must be signed in to change notification settings - Fork 261
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make clear for WASI implementation #514
Comments
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.
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.
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
The intention here is that
Yes, that sounds right to me.
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. |
Thanks for your reply! |
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 WebAssembly/wasi-filesystem#96 about |
I have some questions that need to be confirmed while using WASI and running the WebAssembly/wasi-testsuite.
fs_rights_base
andfs_rights_inheriting
for usingwasi::fd_fdstat_get
on preopen fd?wasi::OFLAGS_EXCL
is a flag that can be used while usingwasi::path_open
, document said that it meansFail if file already exists
. POSIX has a similar flag calledO_EXCL
and it is used to ensure the call creates the file when usingO_CREAT
which means that it is undefined without settingO_CREAT
in POSIX. My question is that what is the behavior forOFLAGS_EXCL
in wasi, should it fail whenever the file exists or fail only whenwasi::OFLAGS_CREAT
is used and the file already exists.wasi::path_open
to open a directory withwasi::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.Thanks in advance!
The text was updated successfully, but these errors were encountered: