[WasmFS] Enforce open file access mode on read/write

[pavelsavara]

Summary

writeAtOffset and readAtOffset in system/lib/wasmfs/syscalls.cpp each carried a
// TODO: Check open file access mode for ... permissions. and never actually checked it.
As a result, WasmFS let you:

• write to a file descriptor opened O_RDONLY, and
• read from a file descriptor opened O_WRONLY,

both of which silently succeeded instead of failing. POSIX write(2)/read(2) require
EBADF when the descriptor is not open for the requested operation.

The change mirrors the check WasmFS already performs in the mmap path
(__syscall_mmap2, which returns -EACCES when the mapping requires an access mode the
descriptor doesn't have).

Motivation

Higher-level runtimes rely on the kernel enforcing the descriptor's access mode. For example,
.NET's System.IO maps EBADF on a write to UnauthorizedAccessException, so tests such as
RandomAccess.Write to a read-only handle and FileStream flushing a buffer on a read-only
handle expect the native write to fail. Under WasmFS these currently pass silently, diverging
from the legacy (MEMFS) JS filesystem and from every other POSIX platform.

Related dotnet/runtime#130141

Behavior change / risk

• Programs that (incorrectly) wrote to O_RDONLY descriptors or read from O_WRONLY
  descriptors and ignored the result will now observe EBADF.

[sbc100]

It looks like the failure of the other.test_wasmfs_jsfile test is probably valid?

Are there any other tests that maybe now pass under wasmfs that did not before?

[pavelsavara]

It looks like the failure of the other.test_wasmfs_jsfile test is probably valid?

Root cause: wasmfs_create_file opens with O_CREAT | O_EXCL, and since O_RDONLY == 0, flags & O_ACCMODE is O_RDONLY - so the returned fd was technically read-only. wasmfs_jsfile.c then writes to it, which the new enforcement (correctly) rejects with EBADF. This was a latent bug that only surfaced once we started enforcing the mode.

Fixed by having wasmfs_create_file open O_CREAT | O_EXCL | O_RDWR, so the returned handle is actually writable. That's also consistent with the legacy FS, which never hands back an implicitly read-only fd on creation.

Are there any other tests that maybe now pass under wasmfs that did not before?

no, nothing newly passes

[tlively]

Code looks good, but we need testing. If there are no existing tests that are now expected to pass, then we should write a new test.