When discussing base and inheriting rights in path_open in #570, we've discovered that, on Unix, our implementation of path_open will implicitly open the derived descriptor with "read" access even when both rights_base and rights_inheriting are set to 0. @marmistrz and I have since been wondering whether this is the intended behaviour or not (for reference, here's the link to the offending bit: sys/unix/hostcalls_impl/fs.rs#L102). Note further that, if you specify __WASI_RIGHT_FD_WRITE, we don't implicitly inherit the read right. All in all then, the possible states for rights_base currently are:

• 0 implies "read" access
• __WASI_RIGHT_FD_READ implies "read" access
• __WASI_RIGHT_FD_WRITE implies "write" access
• __WASI_RIGHT_FD_READ | __WASI_RIGHT_FD_WRITE implies "read-write" access

This could have a potential unexpected behaviour in implementations wrapping the WASI syscalls such as std::fs::OpenOptions which assumes that __WASI_RIGHT_FD_READ is acquired only if the client has indeed specified that they want the path opened for reading which with the current behaviour will not always be the case. Here's the link to the relevant implementation bit in Rust: sys/wasi/fs.rs#L332.