How does `fs_rights_inheriting` work in `path_open`?

[yagehu]

Comment for fs_rights_inheriting says:

    ;;; The *base* rights are rights that will apply to operations using the file
    ;;; descriptor itself, while the *inheriting* rights are rights that apply to
    ;;; file descriptors derived from it.

What does "derived" mean in this context? Examples would be super helpful.

[pchickey]

The rights system and those comments have their roots in CloudABI. In CloudABI, there were a lot of mechanisms through which file descriptors could be derived from others, but in WASI the only mechanism, at the moment, is path_open.

A wrinkle about path_open is that you can use it to open either a file or a directory, depending on the oflags. The descriptor passed to path_open must be a directory, but the derived descriptor can end up having the parent's inheriting rights corresponding to file operations, or corresponding to directory operations, as its base operations.

Since a file (distinct from directory) descriptor has no mechanisms to derive another descriptor from it, the inheriting rights of a file are useless - I would choose to leave them blank, but I guess any value is technically valid.

Its important to note that the documentation of how rights are supposed to work is very insufficient and that implementations vary wildly in how they treat rights. In my opinion, we should re-design and dramatically simplify this mechanism to fit better into the WASI and interface types model better - we now have a lot more clarity on how our capability-based system will work compared to when we started.

[sunfishcode]

#31 will remove the rights system, obviating this.