Clarifying rights::path_filestat_set_size

[MaulingMonkey]

rights::path_filestat_set_size's definition seems fairly ambiguous to me - the current wording is extremely general, "The right to change a file's size.", but then it only describes it's interaction with open. I can't tell if it's meant to:

1. apply broadly to a bunch of syscalls (allocate, filestat_set_size, pwrite/write if extending the file size), or some subset of those, and if so - if it implies, or is implied by, or is required in tandem with related sizing rights that control those syscalls (rights::fd_allocate, rights::fd_filestat_set_size)

or perhaps, at the other extreme:

2. apply only to truncation via open, with the original naming being just to match POSIX.

[sunfishcode]

The background here is that this is evolved from CloudABI's RIGHT_STAT_FPUT_SIZE, which says:

The right to invoke [file_stat_fput] with [fsflags.size].

If [rights.file_open] is set, includes the right to invoke [file_open] with [oflags.trunc].

In WASI terms, this means it applies to filestat_set_size and path_open but not allocate or pread/pwrite.

With that said though, this is a clear example of a broader observation that several people have had about WASI: the rights system is complex to implement, even more complex to use, and not very valuable in practice. On one hand it's too complex for simple use cases where a simple "readonly" flag would suffice, and on the other it's too limiting for many advance use cases, because you only get a bitfield of operations which are either always enabled or always disabled for a given handle. And we'll have other ways to handle the complex use cases, with API virtualization.

So I expect we'll want to simply remove the rights system, rather than put a lot of effort into specifying exactly what each of the rights means.

[sunfishcode]

One thing I should be clear about here is that if individual APIs, such as wasi-nn or wasi-crypto or any others want to have a rights system, they can still do so. My comment here is just about the rights system as it applies to wasi-filesystem, and as I expect it would apply to a wasi-sockets proposal.

[MaulingMonkey]

Fair enough! It's certainly dead weight for my own use cases.

While someone may want permission APIs for the filesystem in the future - perhaps OpenBSD style pledge / unveil - said APIs can always be added later, if/when there are actual motivating use cases and codebases that will take advantage of said APIs.

[sunfishcode]

#31, removing the rights system, is the path forward here.