Or another cool idea use .preinit_array for shared bins and .init_array for static bins and inject a .seccomp, .unshare, etc section that gets called in the preinit, init. This way you can support both shared and static bins with a tiny size increase.
Nerd Sniped by BINFMT_MISC
31–36 of 36 posts
Re: Nerd Sniped by BINFMT_MISC
#32Too bad the more narrow minded segment of the HN population appears to have buried this one out of spite.. because this is some super pro badass shit, packaged in a hilarious format by jessfraz. Guess it's not everyone's kind of humor, a real tradgedy if you ask me. Can you imagine a future where you don't have to install runtimes to run things anymore because they are all distributed with everything you need? It wou…
What you are describing is just a statically linked binary, the world of computing moved away from this well before I started my career but there are pros and cons about it, not only related to disk space.
The world of computing may well be moving back towards this strategy currently. The rise of single-static-binary runtimes (Go, Rust, new Java) and container runtimes (ad hoc, informally-specified static linking for sets of programs) seems to indicate that static linking is far from being consigned to the conceptual rubbish heap.
Re: Nerd Sniped by BINFMT_MISC
#33FWIW, you don't need to fiddle around with binfmt_misc (which requires root permissions) to execute a Go program as a script. The following shebang works: ///bin/true; exec /usr/bin/env go run "$0" "$@" See https://stackoverflow.com/a/30082862/334761 for detailed explanation what's going on there. The only downside is that all exit codes != 0 get mapped to exit code 1 by `go run`. It will show the original exit code…
The downside of that approach is that it only works because shells try to interpret files if a simple execve(2) fails with ENOEXEC. If you wanted to use your fancy .go script with a program that just does execve(2) you'd be in trouble.
Re: Nerd Sniped by BINFMT_MISC
#34FWIW, you don't need to fiddle around with binfmt_misc (which requires root permissions) to execute a Go program as a script. The following shebang works: ///bin/true; exec /usr/bin/env go run "$0" "$@" See https://stackoverflow.com/a/30082862/334761 for detailed explanation what's going on there. The only downside is that all exit codes != 0 get mapped to exit code 1 by `go run`. It will show the original exit code…
That's quite cool, but minor point of pedantry: that's not a shebang. A shebang is interpreted by the operating system, which uses it to find and launch an interpreter for a file.
Compared to that, the example snipped you provided is doing many more, and different things:
1. Launches a shell language interpreter: usually the system default POSIX-compliant sh, but could (rarely) be something else. Compared to "read the first line, and if it's a shebang launch python or whatever" in the kernel, this is massively complicated: it starts another whole runtime. Run "strace" on a file that just does "///bin/true; sleep 1000" to see exactly how much is happening just for that shell launch.
1. Executes /bin/true. It's probably present everywhere, and probably the right program, but still an assumption.
2. Evaluates a bunch of string slinging statements in the shell to interpolate arguments, then replaces itself via "exec".
3. Launches /usr/bin/env (hopefully the right program, and hopefully in the right place) to find the go interpreter.
4. env (hopefully) also calls "exec" again and then launches the go run command to start the compilation/execution sequence.
That's a lot of stuff. Pretty garden-variety stuff, but still a lot of additional complexity. A shebang adds none of it, though "trampolining" shebangs (which themselves are just programs to do basically this) can reintroduce some internally.
That's the beauty of the shebang as a trick for truly interpreted languages: it's extremely direct and simple as a means of getting your code executing on your desired runtime.
Re: Nerd Sniped by BINFMT_MISC
#35Earlier quoted context omitted.
I believe you need to be a on an admin account in Windows to change global file associations. In fairness though, most people are logged in as an Administrator.
You can also have user file associations on Windows though.
Certainly. I supposed the point I am trying to make is that a lot of old windows behaviors that lead to security incidents are finding their way into non-desktop linux machines. My servers have binfmt mounted, for example. SystemD appears to be bringing in a bit of desktop behavior to both desktops and servers. Maybe this is ok if people are aware?
Re: Nerd Sniped by BINFMT_MISC
#36Earlier quoted context omitted.
You can also have user file associations on Windows though.
Certainly. I supposed the point I am trying to make is that a lot of old windows behaviors that lead to security incidents are finding their way into non-desktop linux machines. My servers have binfmt mounted, for example. SystemD appears to be bringing in a bit of desktop behavior to both desktops and servers. Maybe this is ok if people are aware?
binfmt_misc has existed for a much longer time than systemd (it was originally added in 1997[1]). It has been used for many features like emulating binaries "natively" by setting up binfmt_misc so that binaries are executed inside QEMU if the architecture is different. It has had many other similar uses for decades.
I'm not a fan of systemd in the slightest, but blaming systemd for an in-kernel facility that has existed since the mid-90s (and isn't even used by systemd to my knowledge) doesn't make any sense.
[1]: https://elixir.bootlin.com/linux/v4.15.7/source/fs/binfmt_mi...