Stream: git-wasmtime

Topic: wasmtime / Issue #1935 Proposal: add right FD_READ to dir...

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:52):

kubkon opened Issue #1935:

This proposal tackles a situation where, given some directory handle, the user tries to open a subdirectory as a file, and invokes fd_read on the obtained WASI handle. This way, even though they obtained a valid handle from the path_open call (we don't have a way to tell the runtime to fail if the specified subpath is not a file; we can only fail if the subpath is not a directory and we specified the oflag O_DIRECTORY), the fd_read call will fail with ENOTCAPABLE errno since we don't include FD_READ right on directory handles when spawning them. In general, returning ENOTCAPABLE is fine, however, it doesn't match the common (expected?) behaviour of returning EISDIR in this case. Although, having said that, POSIX prescribes we should return EPERM rather than EISDIR. However, it seems that the Linux way of returning EISDIR is treated as standard. @sunfishcode please feel free to correct me here!

@sunfishcode and I had a discussion offline about this, and we both believe it would be reasonable to return EISDIR in this case in WASI as well. To achieve this, we would need to add FD_READ right to directory handles, and in the fd_read and fd_pread calls always return EISDIR errno. Having FD_READ right on the handle would prevent the implementation from failing with ENOTCAPABLE when verifying required rights on the handle.

I've decided to submit an issue about this first before rolling out a PR so that we can all agree if this is the right approach to the presented problem or not. The proposal if lands will introduce a breaking change to the end-user's code in that the expected errno values will change for the chain of syscalls described above.

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:52):

kubkon labeled Issue #1935:

This proposal tackles a situation where, given some directory handle, the user tries to open a subdirectory as a file, and invokes fd_read on the obtained WASI handle. This way, even though they obtained a valid handle from the path_open call (we don't have a way to tell the runtime to fail if the specified subpath is not a file; we can only fail if the subpath is not a directory and we specified the oflag O_DIRECTORY), the fd_read call will fail with ENOTCAPABLE errno since we don't include FD_READ right on directory handles when spawning them. In general, returning ENOTCAPABLE is fine, however, it doesn't match the common (expected?) behaviour of returning EISDIR in this case. Although, having said that, POSIX prescribes we should return EPERM rather than EISDIR. However, it seems that the Linux way of returning EISDIR is treated as standard. @sunfishcode please feel free to correct me here!

@sunfishcode and I had a discussion offline about this, and we both believe it would be reasonable to return EISDIR in this case in WASI as well. To achieve this, we would need to add FD_READ right to directory handles, and in the fd_read and fd_pread calls always return EISDIR errno. Having FD_READ right on the handle would prevent the implementation from failing with ENOTCAPABLE when verifying required rights on the handle.

I've decided to submit an issue about this first before rolling out a PR so that we can all agree if this is the right approach to the presented problem or not. The proposal if lands will introduce a breaking change to the end-user's code in that the expected errno values will change for the chain of syscalls described above.

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:52):

kubkon labeled Issue #1935:

This proposal tackles a situation where, given some directory handle, the user tries to open a subdirectory as a file, and invokes fd_read on the obtained WASI handle. This way, even though they obtained a valid handle from the path_open call (we don't have a way to tell the runtime to fail if the specified subpath is not a file; we can only fail if the subpath is not a directory and we specified the oflag O_DIRECTORY), the fd_read call will fail with ENOTCAPABLE errno since we don't include FD_READ right on directory handles when spawning them. In general, returning ENOTCAPABLE is fine, however, it doesn't match the common (expected?) behaviour of returning EISDIR in this case. Although, having said that, POSIX prescribes we should return EPERM rather than EISDIR. However, it seems that the Linux way of returning EISDIR is treated as standard. @sunfishcode please feel free to correct me here!

@sunfishcode and I had a discussion offline about this, and we both believe it would be reasonable to return EISDIR in this case in WASI as well. To achieve this, we would need to add FD_READ right to directory handles, and in the fd_read and fd_pread calls always return EISDIR errno. Having FD_READ right on the handle would prevent the implementation from failing with ENOTCAPABLE when verifying required rights on the handle.

I've decided to submit an issue about this first before rolling out a PR so that we can all agree if this is the right approach to the presented problem or not. The proposal if lands will introduce a breaking change to the end-user's code in that the expected errno values will change for the chain of syscalls described above.

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:52):

kubkon labeled Issue #1935:

This proposal tackles a situation where, given some directory handle, the user tries to open a subdirectory as a file, and invokes fd_read on the obtained WASI handle. This way, even though they obtained a valid handle from the path_open call (we don't have a way to tell the runtime to fail if the specified subpath is not a file; we can only fail if the subpath is not a directory and we specified the oflag O_DIRECTORY), the fd_read call will fail with ENOTCAPABLE errno since we don't include FD_READ right on directory handles when spawning them. In general, returning ENOTCAPABLE is fine, however, it doesn't match the common (expected?) behaviour of returning EISDIR in this case. Although, having said that, POSIX prescribes we should return EPERM rather than EISDIR. However, it seems that the Linux way of returning EISDIR is treated as standard. @sunfishcode please feel free to correct me here!

@sunfishcode and I had a discussion offline about this, and we both believe it would be reasonable to return EISDIR in this case in WASI as well. To achieve this, we would need to add FD_READ right to directory handles, and in the fd_read and fd_pread calls always return EISDIR errno. Having FD_READ right on the handle would prevent the implementation from failing with ENOTCAPABLE when verifying required rights on the handle.

I've decided to submit an issue about this first before rolling out a PR so that we can all agree if this is the right approach to the presented problem or not. The proposal if lands will introduce a breaking change to the end-user's code in that the expected errno values will change for the chain of syscalls described above.

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:52):

kubkon labeled Issue #1935:

This proposal tackles a situation where, given some directory handle, the user tries to open a subdirectory as a file, and invokes fd_read on the obtained WASI handle. This way, even though they obtained a valid handle from the path_open call (we don't have a way to tell the runtime to fail if the specified subpath is not a file; we can only fail if the subpath is not a directory and we specified the oflag O_DIRECTORY), the fd_read call will fail with ENOTCAPABLE errno since we don't include FD_READ right on directory handles when spawning them. In general, returning ENOTCAPABLE is fine, however, it doesn't match the common (expected?) behaviour of returning EISDIR in this case. Although, having said that, POSIX prescribes we should return EPERM rather than EISDIR. However, it seems that the Linux way of returning EISDIR is treated as standard. @sunfishcode please feel free to correct me here!

@sunfishcode and I had a discussion offline about this, and we both believe it would be reasonable to return EISDIR in this case in WASI as well. To achieve this, we would need to add FD_READ right to directory handles, and in the fd_read and fd_pread calls always return EISDIR errno. Having FD_READ right on the handle would prevent the implementation from failing with ENOTCAPABLE when verifying required rights on the handle.

I've decided to submit an issue about this first before rolling out a PR so that we can all agree if this is the right approach to the presented problem or not. The proposal if lands will introduce a breaking change to the end-user's code in that the expected errno values will change for the chain of syscalls described above.

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:52):

github-actions[bot] commented on Issue #1935:

Subscribe to Label Action

cc @kubkon

<details>
This issue or pull request has been labeled: "wasi"

Thus the following users have been cc'd because of the following labels:

• kubkon: wasi

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:59):

kubkon commented on Issue #1935:

I should also mention that the alternative could be some post-processing/errno remapping in the libc (or equivalent). @sunfishcode already pointed out that some post-processing in fd_read already happens in wasi-libc.

Wasmtime GitHub notifications bot (Jun 28 2020 at 19:59):

kubkon edited a comment on Issue #1935:

I should also mention that the alternative could be some post-processing/errno remapping in the libc (or equivalent). @sunfishcode already pointed out that some post-processing in read already happens in wasi-libc.

Wasmtime GitHub notifications bot (Jun 30 2020 at 17:29):

pchickey commented on Issue #1935:

This seems like a reasonable approach to implementing the current interface. If we could kick this problem up to design changes in the WASI interfaces themselves, I would love some way to distinguish between directory handles and file handles in the type system so that doing file operations on a directory is caught as a type check rather than a capability check.

Wasmtime GitHub notifications bot (Jun 30 2020 at 23:07):

sunfishcode commented on Issue #1935:

I agree with @pchickey; we should work towards having directories be a separate type, with separate rights, and make this a type error caught at runtime and translated by libc into EISDIR. But for now, using FD_READ seems a simple and unintrusive way to fix the immediate problem.

Wasmtime GitHub notifications bot (Jul 01 2020 at 15:26):

kubkon edited a comment on Issue #1935:

OK then, I'll submit a patch to that effect that will fix it as discussed.

Wasmtime GitHub notifications bot (Jul 01 2020 at 15:26):

kubkon commented on Issue #1935:

OK, then, I'll submit a patch to that effect that will fix it as discussed.

Last updated: Dec 23 2024 at 13:07 UTC