On 25/06/2025 23:00, Nadav Tasher wrote:
On Wed, Jun 25, 2025 at 11:54:56AM +0200, Csókás Bence wrote:
Okay, I understand it for system(), but for the execv() one, the only reason
for a developer to write that one is when they _explicitly_ want to honor
the user's shell preference. Which now we disregard completely.
Actually, I'm not sure about that.
In the entire BusyBox codebase, the only times a shell is executed using
get_shell_name(), is when system() is insufficient (like when you need to
capture
the output or pipe the shell to another process).
That is not right.
get_shell_name() is used in:
- tar --to-command
- openvt when no command is specified
- chroot when no command is specified
- adduser as the default shell for new users
- conspy
- crond
- ifupdown
- svlogd
- flock
- script
Of those, the *only* one where it is assumed to be sh-like is ifupdown.
In all other instances, busybox does not pass any commands beyond what
is specified by the user, where it seems reasonable to run that in
whatever shell the user wants, whether that be sh-like or not.
I get what you're going for but I think this is the wrong way of doing
it. get_shell_name() uses, in order of preference, the SHELL environment
variable, the shell specified in /etc/passwd, DEFAULT_SHELL. With your
new config option, DEFAULT_SHELL could be "sh" (or maybe "-sh" to
continue to act as a login shell), but it does not look right that the
other two would be ignored. If the user requests a different shell, let
the user get that different shell.
Cheers,
Harald van Dijk
_______________________________________________
busybox mailing list
busybox@busybox.net
https://lists.busybox.net/mailman/listinfo/busybox
