4 ms·
Defeats the point of WASI—WASIX seems not to be capabilities based
by nynx 3y ago
Defeats the point of WASI—WASIX seems not to be capabilities based
- garganzol 3y agoI do not see a problem in that. You can always restrict the capability by not exporting a particular API function, or just by returning ENOPERM. It's the job of an operating environment to decide which permissions are available.
- boricj 3y agoWASIX seems to be basically POSIX for WASM (POSIX/WASIX). It is probably an explicit design goal to be able to run POSIX-compliant programs on it. The fact that POSIX is 1970s legacy, rusted beyond salvaging and an extremely poor fit for modern system designs and expectations is another problem.
- nsonha 3y agoWhat would be a modern alternative?
- boricj 3y agoThe only other equivalent API in broad use today that I'm aware of would be the Kernel32.dll subset of Win32 [1]. Not that it's perfect (so much accumulated cruft) or what I would call modern (still has a lot of ambient authority baked-in) by any means, but the important parts are mostly handle-based (unlike PID-based POSIX process management functions for example). I happen to like the design of the syscall layer of Fuchsia's Zircon kernel [2], but it's not a full substitute for POSIX (notably, file and network I/O are built as userspace features of top of IPC channels, they are not kernel concepts). [1] https://www.geoffchappell.com/studies/windows/win32/kernel32/api/index.htm https://www.geoffchappell.com/studies/windows/win32/kernel32... [2] https://fuchsia.dev/fuchsia-src/reference/syscalls https://fuchsia.dev/fuchsia-src/reference/syscalls