Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WASI and POSIX? #122

Open
kripken opened this issue Oct 18, 2019 · 4 comments

Comments

@kripken
Copy link
Member

@kripken kripken commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@bjorn3 bjorn3 commented Oct 18, 2019

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

This comment has been minimized.

Copy link
Member

@sbc100 sbc100 commented Oct 18, 2019

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

This comment has been minimized.

Copy link
Member

@sunfishcode sunfishcode commented Oct 18, 2019

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

This comment has been minimized.

Copy link

@AndrewScheidecker AndrewScheidecker commented Oct 18, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.