On 26/06/2025 23:18, Nadav Tasher wrote:
On Thu, Jun 26, 2025 at 10:38:14PM +0100, Harald van Dijk wrote:
I don't really see why you would want this even as a Kconfig option,
personally, but perhaps I do not understand your use case well enough. I get
why you want to have the default behaviour to be to execute things
internally, and I support that. I don't get why you want to also execute
things internally when the user requests not to execute things internally.
Could you explain why you want that?
Yes, I'll elaborate.
This patchset aims to provide a way to compile BusyBox so that it generates a
completely stand-alone binary (and by that I do not necessarily mean a static
binary), that acts as a full (or partial, user decides) *NIX system.
This means that applets will try to execute other applets, before falling back
to binary executions (a Kconfig to forbid external executions also exists).
Since that is the desired behaviour, any applet that uses the system() function
or exec*() with get_shell_name(), needs to run a BusyBox-internal shell, so that
this shell will keep on calling internal applets (by function) instead of
executing external binaries.
That doesn't sound quite right. Any applet that uses system() or
get_shell_name() should run a busybox-internal shell when the user
account is not specifically configured to use a different shell, agreed
so far. But I'm talking about the scenario where it *is* configured to
use a different shell. What scenario do you have in mind where the user
would be set up use a different shell, but you want to use the internal
shell anyway?
Thinking about this more, I think this introduces a massive security
vulnerability that it starts allowing shell execution for accounts that
specify a shell of /sbin/nologin or equivalent.
Cheers,
Harald van Dijk
_______________________________________________
busybox mailing list
[email protected]
https://lists.busybox.net/mailman/listinfo/busybox
