WASI and POSIX?

[kripken]

I'm curious to hear what people think about how much of POSIX should be possible to implement via WASI.

As a concrete example, I may be wrong but I think you can't implement the commandline tool ls in WASI atm, because WASI can't represent the owner/group/world permission levels (there is just "read" permission, but not separately for the owner/group/world, etc.). That is, if one tried to port ls to wasi, I'm not sure how it could print the rwx etc. stuff here;

$ ls -al foo
-rwxrwxr-x 1 me me 117312 Oct 17 19:10 foo

ls may seem trivial, but this also limits how much Python's system libraries can be ported, for example, as people do use Python to script operations on POSIX permissions. So the system ls, python, etc. seem to not be replaceable by wasi alternatives atm.

Of course file permissions is just an example of something that seems not possible in wasi atm. I'm more curious about the general thinking here. Maybe there could be an optional wasi POSIX module (which would have a posix_path_open that parallels path_open)? Or maybe 100% POSIX support isn't a use case people here care about?

[bjorn3]

Use POSIX permissions would make it basically impossible to implement WASI on Windows, as Windows uses ACL's instead of user/group/world read/write/execute/suid.

[sbc100]

I think there are conflicts between POSIX and the design philosophy of WASI. So it seems that full POSIX support is (by design) not goal for WASI. I believe this is also true of cloudabi on which WASI was initially based. I think the idea is the its better to break compatibility for the sake of a better, brighter tomorrow.

This does mean I guess that the is room, perhaps not in WASI, to design something more POSIX-ey.

[sunfishcode]

It would be very valuable to WASI for people to report real-world POSIX programs they wish to run on WASI but which don't work due to WASI's limitations. Obviously there are some big things, like networking, which we do intend to add.

I'd be really interested in hearing whether people actually need, for example, full POSIX-style "user/group/other read/write/execute" permissions control in the kinds of programs they want to use wasm for, and how they're being used. Since these have unclear meaning on Windows, and even have some implementation-defined behavior in some of the finer details even on ostensibly POSIX systems, the more we know about how people actually want to use these, as opposed to how they could theoretically use them, the more flexibility we'll have.

[AndrewScheidecker]

I do hope that WASI can gradually support most of POSIX, including forking, signals, sockets, and shared memory. Maybe even getcwd!

I think there are conflicts between POSIX and the design philosophy of WASI.

I don't think that's true: WASI-libc already goes out of its way to emulate the POSIX file API via libpreopen, and it seems like it should be possible to emulate the rest of POSIX on top of whatever OCAP-based APIs WASI adopts in a similar way.

Use POSIX permissions would make it basically impossible to implement WASI on Windows, as Windows uses ACL's instead of user/group/world read/write/execute/suid.

It might not be possible to map file permissions 1:1 between POSIX and Windows, but some useful mapping should be possible.

I'd be really interested in hearing whether people actually need, for example, full POSIX-style "user/group/other read/write/execute" permissions control in the kinds of programs they want to use wasm for, and how they're being used.

I don't need file permissions, but it's incredibly valuable for existing POSIX programs to compile and do something sensible.