Add functions for working with file permissions.

[sunfishcode]

Add functions and types to query and set the filesystem permissions of
a file: read, write, execute (for files), and search (for directories).

These permissions aren't the only thing which determines whether a given
file or directory can be accessed; hosts may impose additional arbitrary
security restrictions not reflected here.

WASI itself does not currently have the ability to execute files, so the
meaning of "execute" here is entirely up to the host filesystem.

These are similar to fchmod/fchmodat/fstat/fstatat in POSIX, though
there are some differences:

• This doesn't surface POSIX's setuid, setgid, or sticky bits. These can
  be added in the future if needed, though they'll require additional
  security and portability considerations.

• This uses separate flags for "execute" on files vs "search" on
  directories. WASI libc can provide a POSIX-compatible C API.

• This doesn't expose POSIX's user/group/other concepts. These can be
  added in the future if needed, though they'll require additional
  security and portability considerations. Implementations in POSIX
  environments should follow the umask when setting permissions flags.

[Edit - added discussion about user/group/other].

[bjorn3]

Maybe just split user and everyone permissions? Those should be supported on both UNIX and Windows systems. Relying on umask doesn't seem very nice, as not everyone knows about the existence of umask. Also you may want to prevent reading private keys by everyone, while the default umask on most systems enables read for everyone by default.

[sbc100]

It not clear to me why we would need a separate permission_get. Why not just have the permission be part of the path_filestat_get result? It there some platform where getting permission is more expensive than, say, the mtime of a file?

Otherwise lgtm.

[sunfishcode]

@sbc100

It not clear to me why we would need a separate permission_get. Why not just have the permission be part of the path_filestat_get result? It there some platform where getting permission is more expensive than, say, the mtime of a file?

Not a super strong opinion here. I've now changed it to work as you suggest.

I do have a feeling that filestat is too monolithic, but if we do split it up, that can be a separate conversation.

@bjorn3

Maybe just split user and everyone permissions? Those should be supported on both UNIX and Windows systems. Relying on umask doesn't seem very nice, as not everyone knows about the existence of umask. Also you may want to prevent reading private keys by everyone, while the default umask on most systems enables read for everyone by default.

That's a good point. I want to keep this as simple as possible, but maybe what we can do is add a $private permission flag, and say that path_open interprets the flag as:

• if $private is unset, follow umask
• if $private is set, follow umask | 0077

I'm imagining filestat_get on POSIX hosts could do this:

read    = (st_mode & (S_IRUSR | S_IRGRP | S_IROTH)) != 0 ||
          (S_ISDIR(st_mode) && (st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) != 0);
write   = (st_mode & (S_IWUSR | S_IWGRP | S_IWOTH)) != 0;
execute = (st_mode & (S_IXUSR | S_IXGRP | S_IXOTH)) != 0 &&
          !S_ISDIR(st_mode);
private = (st_mode & (S_IRGRP | S_IWGRP | S_IXGRP | S_IROTH | S_IWOTH | S_IXOTH)) == 0;

I've now add $private to the PR so we can iterate from here.

[sbc100]

lgtm, although perhaps the initial version does't need the "private" concept? It seems rather limited, and could be added later after more discussion perhaps?

[sunfishcode]

With the snapshot development model, we don't need to commit to this right now. The private concept should address @bjorn3's use case above of writing private keys, so unless there are specific concerns, I'm inclined to keep it until we get some real-world experience with it.