[WASI] Should we overlook or restrict the access modes for stdin/stdout/stderr?

[lum1n0us]

We've observed that in certain situations, the access modes for STDIN, STDOUT and STDERR do not behave as anticipated. For example, STDOUT may be read-only, while STDIN may be write-only.

It's important that we look into why these unexpected access modes are occurring. However, I'm wondering if we need to take steps to block these incorrect settings in core/iwasm/libraries/libc-wasi

Specifically, when determining file descriptor rights in the function fd_determine_type_rights(), should we assign fixed and unchangeable rights to STDIN, STDOUT and STDERR?

[wenyongh]

I saw the PR #3694 sets the STDIN rights with:

(__WASI_RIGHT_FD_ADVISE | __WASI_RIGHT_FD_FILESTAT_GET | \
  __WASI_RIGHT_FD_READ | __WASI_RIGHT_POLL_FD_READWRITE)

not sure will it disable the write right for STDIN and disable the read right for STDOUT? It seems the similar issues were reported before, but after discussion with @yamt, we decided not to change the code:
#2645 (comment)
#2606

[yamt]

We've observed that in certain situations, the access modes for STDIN, STDOUT and STDERR do not behave as anticipated. For example, STDOUT may be read-only, while STDIN may be write-only.

It's important that we look into why these unexpected access modes are occurring. However, I'm wondering if we need to take steps to block these incorrect settings in core/iwasm/libraries/libc-wasi

yes, please investigate the situation further before making changes to libc-wasi.

[lum1n0us]

The problem originated from integrating WAMR with runwasi, which aims to run a WebAssembly runtime within containerd. I haven't pinpointed the exact issue yet, but there are some unanticipated behaviors occurring within their sandbox environment. Like, fcntl(STDOUT, F_GETFL, 0) returns O_RDONLY. The unusual result will strip off write bits.

Then I made an trial on linux.

$ cat demo.c
int main() {
    int ret;

    ret = fcntl(STDOUT_FILENO, F_GETFL);
    printf("fcntl(stdout, F_GETFL)=%d\n", ret);

    ret = fcntl(STDOUT_FILENO, F_SETFL, O_RDONLY);
    perror("fcntl(stdout, F_SETFL, O_RDONLY)");

    ret = fcntl(STDOUT_FILENO, F_GETFL);
    printf("fcntl(stdout, F_GETFL)=%d\n", ret);

    return EXIT_SUCCESS;
}
$ clang -o demo demo.c
$ demo
fcntl(stdout, F_GETFL)=2
fcntl(stdout, F_SETFL, O_RDONLY): Success
fcntl(stdout, F_GETFL)=2

IIUC, this suggests that the access mode for STDOUT cannot be altered. As a result, it appears that the access mode for STDOUT ought to remain fixed, making any previous removal of write permissions unnecessary.

If everyone is in consensus that the access modes for STDIN, STDOUT, and STDERR are fixed and cannot be altered, then we can begin to discuss the suitable combinations of permissions for these three streams.

[wenyongh]

Agree that the access modes for STDIN, STDOUT and STDERR should be fixed, and suggest adding __WASI_RIGHT_FD_READ | __WASI_RIGHT_FD_WRITE to the rights of them all.

[yamt]

Then I made an trial on linux.

this experiment doesn't seem make sense.
i don't think you can alter O_RDONLY with F_SETFL on any descriptors.

[lum1n0us]

i don't think you can alter O_RDONLY with F_SETFL on any descriptors.

The trial is about asserting that the access mode of STDXXX should be the default value set by the OS and should remain unchanged. fd_determine_type_rights() should not use the result of os_file_get_access_mode() to strip either read or write bits. Additionally, considering STDXXX has a known file type, there is no need to involve os_fstat() and the subsequent switch-case. We can simply provide fixed rights for STDXXX. But seems I forgot __wasi_filetype_t *type is an output parameter

[yamt]

i don't think you can alter O_RDONLY with F_SETFL on any descriptors.

The trial is about asserting that the access mode of STDXXX should be the default value set by the OS and should remain unchanged. fd_determine_type_rights() should not use the result of os_file_get_access_mode() to strip either read or write bits.

why not?

Additionally, considering STDXXX has a known file type, there is no need to involve os_fstat() and the subsequent switch-case. We can simply provide fixed rights for STDXXX. But seems I forgot __wasi_filetype_t *type is an output parameter

it's simpler to avoid special cases for fd 0-2 if possible.

[lum1n0us]

why not?

Like you mentioned before, can't alter O_RDONLY with F_SETFL. Therefore there will be an assumption that access mode returned by os_file_get_access_mode() is able to be trusted(because they are configured by OS), fd_determine_type_rights() should use that to strip either read or write bits(like OS will allow write into STDOUT and read from STDIN). But the unexpected result in our case suggest other possibilities that OS might not set those access modes correctly(like OS will not allow write into STDOUT and read from STDIN).

[lum1n0us]

it's simpler to avoid special cases for fd 0-2 if possible.

I think that is what we did in PR.