Good day Nadav. Looks like you did a lot of work. I would like to incorporate what is useful, and discuss the changes I do not understand.
By "making BusyBox self-contained", what do you have in mind? self-contained as in independent? Independent from what? On Mon, Nov 17, 2025 at 12:09 AM Nadav Tasher <[email protected]> wrote: > libbb: mask xvfork to xfork on MMU targets Above seems to be unnecessary. > libbb: implement clone_string_array > libbb: implement close_cloexec_fds > libbb: implement reset_all_signals > libbb: implement bb_execXX function family to handle applet executions > libbb: make spawn and spawn_and_wait use bb_execvp > libbb: implement bb_system using spawn_and_wait libbb changes like these need to go in with the corresponding change which needs them. +config FEATURE_TRY_BASENAME_APPLETS + bool "fake PATH lookup using basename" + default n + depends on FEATURE_PREFER_APPLETS + help + This makes applet lookup try the basename of the applet name given, + essentially allowing applet execution by absolute path. This might be useful. Perhaps you can add a short explanation in *what use case* you find it useful? It's not "faking" PATH lookup: PATH lookup is not done on filenames with slashes. This needs a better name and description. FEATURE_PREFER_APPLETS_IN_BASENAME? Still not really satisfactorily explanatory. FEATURE_PREFER_APPLETS_EVEN_WITH_PATH? That's... wordy, but hopefully not misleading? + This feature extends the "exec prefers applets" feature. Above part of the description is not necessary. +config FEATURE_FORCE_APPLETS + bool "only use applets" + default n + depends on FEATURE_PREFER_APPLETS + help + This is an experimental option which makes exec calls fail when trying + to execute external binaries that are not part of busybox. Why is this useful? Please add a short explanation in *what use case* you find it useful. If we are adding these CONFIGs, they need to go in as a separate patch which adds just that change, with no other changes. In fact, it can be a separate patch, applied to the current tree, not a part of a large patch set - easier to review and apply. > applets: change system() calls to bb_system() > libbb: make bb_system use get_shell_name to find shell These two changes make sense in the spirit of FEATURE_PREFER_APPLETS: users may want to use an internal shell instead of external "/bin/sh", as defined by libc system() API. Perhaps they do not want to depend on existence of "/bin/sh". Maybe call it FEATURE_PREFER_INTERNAL_SHELL? There is already support for having internal shell even if neither ash nor hush is selected as applet: shell/hush.c // This option is visible (has a description) to make it possible to select // a "scripted" applet (such as NOLOGIN) but avoid selecting any shells: //config:config SHELL_HUSH //config: bool "Internal shell for embedded script support" //config: default n This means that bb_system() can simply follow this existing example how to call internal shells: int scripted_main(int argc UNUSED_PARAM, char **argv) { int script = find_script_by_name(applet_name); if (script >= 0) # if ENABLE_SHELL_ASH return ash_main(-script - 1, argv); # elif ENABLE_SHELL_HUSH return hush_main(-script - 1, argv); # else return 1; # endif return 0; } Can you send a separate patch (not a part of a larger patch set) which implements this? > libbb: allow forcing all applets to behave as NOEXEC applets Maybe makes sense. If you describe a case where you are using it. I suspect this *requires* aliasing vfork() to fork() to avoid a lot of problems? > shell: support shell aliases for ash and hush IOW: instead of support for just "bash" alias, you want support for arbitrary shell name aliases. Good idea! Can you send a separate patch (not a part of a larger patch set) which implements this? > applets: use bb_execXX functions instead of direct exec calls The above change needs to be combined with "libbb: implement bb_execXX" change so that it's easier to review and (1) see why bb_execXX are useful, and (2) be sure we aren't breaking things. > ash: use bb_execve to execute commands and applets in tryexec > hush: use bb_execvp to execute commands and applets in execvp_or_die Shells are fragile beasts. This should go in after the previous "applets: use bb_execXX" patch is reviewed and applied. Absolutely do run the "run_all" scripts in shell/ash_test and shell/hush_test before submitting this change (run them with various combinations of CONFIGs, note in your submission what config(s) you tested). > libbb: implement re_exec using bb_execv >By using bb_execv, an applet can be executed with NOEXEC >instead of actually re-executing the binary You seem to misunderstand the purpose of re_exec(). It's used exclusively on NOMMU to re-execute the same applet after vfork() in the applet, in order to unblock the parent and have two instances of the applet code to run in parallel. Examine httpd.c to see how and why it's done. This is a work-around for an inability to use fork() on NOMMU machines. Making re_exec() "NOEXEC-capable" defeats the purpose why it exists. _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
