This repository was archived by the owner on Nov 25, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 25, 2025. It is now read-only.
Clarifying rights::path_filestat_set_size #28
Description
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:
- apply broadly to a bunch of syscalls (
allocate,filestat_set_size,pwrite/writeif 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:
- apply only to truncation via
open, with the original naming being just to match POSIX.
Activity
sunfishcode commentedon Mar 10, 2021
The background here is that this is evolved from CloudABI's
RIGHT_STAT_FPUT_SIZE, which says:In WASI terms, this means it applies to
filestat_set_sizeandpath_openbut notallocateorpread/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 commentedon Mar 10, 2021
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 commentedon Mar 14, 2021
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 commentedon Dec 15, 2021
#31, removing the rights system, is the path forward here.