The installer script should register Wasmer as a new binfmt_misc interpreter on Linux

lilianmoraru commented 5 years ago

Motivation

On Linux, Wasmer could use binfmt_misc to allow users to run WASM binaries like any other binary, without even knowing the wasmer name or flags.

Proposed solution

The installer script should register Wasmer as a new binfmt_misc interpreter.

Additional context

QEMU uses this feature to run for example ARM binaries on x86_64 PCs. The package on Ubuntu that adds these configurations for QEMU is called qemu-user-binfmt. In order to make this work, binfmt-support might be required.

jcaesar commented 4 years ago

I guess this would need some kind of wrapper (script), as just adding :wasm:M::\x00asm\x01\x00\x00::/usr/bin/wasmer: (to /usr/lib/binfmt.d/wasm.conf for systemd-binfmt) only works correctly if you don't pass any arguments.

[Edit:] I currently have this set up as

/usr/lib/binfmt.d/wasm.conf
:wasm:M::\x00asm\x01\x00\x00::/usr/local/bin/wasmerwrapper:
/usr/local/bin/wasmerwrapper
#!/usr/bin/env sh exec /usr/bin/wasmer -- "$@"`

Hywan commented 3 years ago

@jcaesar Can you please open a PR? It seems to be a really good feature to provide!

jcaesar commented 3 years ago

Could, but I learned some new stuff and now I kind-of don't want to, the way it is currently.

I'd like to support passing arguments like --dir (probably from environment variables)
I'd like for this to work in docker / lxc / ...

The latter point is a bit tricky. You need to set the F and C flag on the binfmt_misc spec, and then make sure that whatever interpreter you specified is a static executable. The question is... do you want to ship an extra executable just for this? (qemu does.) Or do you want to mess up wasmer-cli's command structure so that it will first check if $1 is a wasm binary and execute it if so?

jcaesar commented 3 years ago

(Experimented a bit. binfmt-interpreting wasm files in docker containers is definitely doable: https://github.com/jcaesar/universal-docker-containers#experiment And of course I'm not the first person to have this idea.)

Hywan commented 3 years ago

do you want to ship an extra executable just for this?

Yeah, nothing against that.

Or do you want to mess up wasmer-cli's command structure so that it will first check if $1 is a wasm binary and execute it if so?

It depends how complex that is, but I'm not against neither.

jcaesar commented 3 years ago

It depends how complex that is, but I'm not against neither.

Not awfully complex, but it'll stay relatively nasty for UX in some edge cases: binaries may be named the same was wasmer-cli subcommands. From what I see, there is nothing that would allow you to know that you're currently being run as a binfmt-interpreter or not.

Any ideas what to do about preopened directories? If WASI had a concept of $CWD and you could preopen /, that'd be nice…

jcaesar commented 3 years ago

From what I see, there is nothing that would allow you to know that you're currently being run as a binfmt-interpreter or not.

Correction: If you hardlink or copy, $0 will be set to whatever path you registered the binfmt interpreter from. I suppose I'll do a PR that:

Adds a register-binfmt subcommand to wasmer-cli (on linux, with nice arguments to configure all the paths and whatnot) which
1. copies $0 to /tmp/wasmer-exec
2. Checks whether /tmp/wasmer-exec is a statically linked executable and prints a warning otherwise
3. Does the magic in /proc/sys/fs/binfmt_misc/wasm
Add a startup check to wasmer-cli that checks whether basename $0 is wasmer-exec, and then doesn't invoke the normal argument parser
- Maybe I should check whether /tmp exists before enabling the normal caching
- Pick compiler and preopened directories from some WASMER_BINFMT_ env variables

~~And a second PR that:~~

~~Alters the CI so that wasmer is built and distributed as a statically linked executable~~ Nvm, https://github.com/wasmerio/wasmer/releases/download/2.0.0/wasmer-linux-musl-amd64.tar.gz already exists.

jcaesar commented 2 years ago

@lilianmoraru Doing the registering in the startup script would now be relatively easy. But I have one conceptual problem with it: The install script installs wasmer for one user, who could easily modify the wasmer executable. But the registration is global. A user-controlled file will be executed if root runs a wasm file. If you have a good suggestion for how to deal with that, please do tell.

My ideas so far:

wasmer could be installed as root (wapm not so much, but the install could split)
a prompt could explain the problem to the user and ask if he doesn't care (most systems are single-user, and if the main account is compromised, an exploit only needs to wait until the next time somebody says "sudo")

SamuraiCrow commented 2 years ago

Arch/Manjaro Linux already has WAPM as a separate package from Wasmer. It's currently in AUR though which is essentially installing from source using a script.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

syrusakbary commented 1 year ago

not stale

stale[bot] commented 8 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

stale[bot] commented 7 months ago

Feel free to reopen the issue if it has been closed by mistake.

wasmerio / wasmer