Timeline for Are BusyBox commands truly built in?
Current License: CC BY-SA 4.0
23 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 4, 2021 at 12:37 | comment | added | Gilles 'SO- stop being evil' | @august0490 You could download Debian's busybox-static binary. Extract /bin/busybox-static from the .deb package and it'll work on any system with a non-antique Linux kernel and the matching processor architecture. | |
| Mar 4, 2021 at 12:35 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 4.0 | added 150 characters in body |
| Mar 4, 2021 at 6:05 | comment | added | august0490 | busybox show the error applet not found when I try to use the echo command in a distroless docker image like gcr.io/distroless/java-debian10:11. Is there any repository to download a compiled binary of busybox with FEATURE_SH_STANDALONE and FEATURE_PREFER_APPLETS enabled? | |
| Apr 5, 2016 at 23:05 | comment | added | Wildcard | The third bullet point now fully answers my question. So, given the availability of /proc/self/exe and given a BusyBox binary compiled with FEATURE_SH_STANDALONE and FEATURE_PREFER_APPLETS, all BusyBox commands would indeed be fully available so long as BB itself were running. Thanks very much; accepted! | |
| Apr 5, 2016 at 23:03 | vote | accept | Wildcard | ||
| Apr 5, 2016 at 10:53 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 3.0 | FEATURE_SH_STANDALONE requires FEATURE_PREFER_APPLETS (thanks muru); fixed bad copy-paste of applet lists (thanks Keith Hall) |
| Apr 5, 2016 at 10:48 | comment | added | Keith Hall | @Giles, the bullet points for noexec and nofork currently show the opposite examples than they should - Applets that are declared as “noexec” in the source code are executed as function calls in a forked process. As of BusyBox 1.22, the following applets are nofork | |
| Apr 5, 2016 at 10:08 | history | edited | muru | CC BY-SA 3.0 | deleted 11 characters in body |
| Apr 5, 2016 at 10:06 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 3.0 | explain the implication on calling a deleted program |
| Apr 5, 2016 at 10:01 | comment | added | Gilles 'SO- stop being evil' | @Wildcard Nofork and noexec are indications set on each applet. FEATURE_xxx is a compile-time option for BusyBox as a whole. The nofork and noexec indications only matter if FEATURE_PREFER_APPLETS is active (at least for the purpose of executing a command in the shell, they're also used in some other contexts). | |
| Apr 5, 2016 at 9:59 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 3.0 | reworded to clarify the conditionals per comment request |
| Apr 5, 2016 at 7:24 | comment | added | hvd | @forest There's a huge difference: tac requires either a seekable input file which is not always available, or reading the entire input into memory. cat can read its input from start to finish, discarding what it's already processed. It's much easier to implement and it's also much more commonly used, so it makes more sense to optimise that one. | |
| Apr 5, 2016 at 5:57 | comment | added | forest | Why would cat be nofork but tac be noexec? I mean, there shouldn't be any fundamental difference between the two. | |
| Apr 5, 2016 at 2:40 | comment | added | Barefoot IO | On an Ubuntu 14.04.1 LTS system, Busybox is configured to prefer applets. Since neither cat nor chmod require exec-ing a pathname, you can recover the executable thusly: cat /proc/self/exe > busybox; chmod 755 busybox. | |
| Apr 5, 2016 at 2:38 | comment | added | muru | @Wildcard FEATURE_SH_STANDALONE (which requires FEATURE_PREFER_APPLETS). nofork isn't needed. With FEATURE_SH_STANDALONE, /proc/self/exe is used where applicable, so it will work even if BB was deleted. You can test this out with fairly minimal risk on any Debian or Arch Linux systm, run busybox ash, unset PATH, do basin's commands. It works fine. | |
| Apr 5, 2016 at 2:23 | comment | added | Wildcard | Thanks, @muru. In summary then it looks like to get the behavior of "able to run all (or nearly all) BB commands from a running BB instance even if the binary is deleted," BB would need to be compiled with FEATURE_PREFER_APPLETS, FEATURE_SH_STANDALONE and FEATURE_SH_NOFORK? | |
| Apr 5, 2016 at 2:04 | comment | added | muru | @Wildcard FEATURE_PREFER_APPLETS and FEATURE_SH_STANDALONE are compile-time flags, enabling or disabling features. The applets are marked nofork and noexec irrespective of which flags were used. Whether or not such markings have any effect depends on FEATURE_PREFER_APPLETS being enabled. Hence, three possible behaviours: 1. FEATURE_PREFER_APPLETS disabled, 2. FEATURE_PREFER_APPLETS enabled and applet is nofork, 3. FEATURE_PREFER_APPLETS enabled and applet is noexec. The third para in the docs explain it nicely. And the last section shows the possible cases. | |
| Apr 5, 2016 at 1:32 | comment | added | Wildcard | This is a great answer, but I'm having a little trouble following the conditionals. It seems there are four values/variables that could have an effect on the behavior of any given command: FEATURE_SH_STANDALONE, FEATURE_PREFER_APPLETS, nofork and noexec. Could you please clarify how these four factors interact? I only see two possible behaviors in the final outcome, as specified in my question; why the dual flags "nofork" and "noexec"? | |
| Apr 5, 2016 at 1:27 | history | edited | Wildcard | CC BY-SA 3.0 | Add a couple line breaks for easier reference |
| Apr 5, 2016 at 1:23 | history | edited | muru | CC BY-SA 3.0 | typo fixes, made a list to break up the loong sentence |
| Apr 5, 2016 at 1:16 | comment | added | Gilles 'SO- stop being evil' | @Wildcard I included a bit too much when I extracted the list from the source code. Fixed, thanks. | |
| Apr 5, 2016 at 1:16 | history | edited | Gilles 'SO- stop being evil' | CC BY-SA 3.0 | deleted 112 characters in body |
| Apr 5, 2016 at 1:11 | history | answered | Gilles 'SO- stop being evil' | CC BY-SA 3.0 |