Several issues with busybox-1.30

[dbrll]

I'm migrating my userland from GNU Coreutils to Busybox and have noticed several issues with the Void package.

• CONFIG_FEATURE_USERNAME_COMPLETION not set in .config.
  That means the autocompletion will not work for $HOME, which is annoying when using busybox as a login shell. There is no apparent reason why this flag shouldn't be set.

• If /bin/ash doesn't exist, the package should create a symlink /bin/ash -> /bin/busybox and add it to /etc/shells. This needs to be done manually so far.

• "ping" applet doesn't work
  Since adding a suid flag on /bin/busybox is out of question, the following should be done instead:

setcap cap_net_raw=ep /bin/busybox  # set capability for raw sockets on the binary
sysctl -w net.ipv4.ping_group_range=1 4  # allow GIDs 1 to 4 (wheel) to ping (should be added to /etc/sysctl.conf)

• "less" only show the first line of the file. I couldn't figure this one. Building from the upstream sources provides a working applet so this seems specific to the package.

• The static build will most likely be used in the initramfs as a rescue shell, or as the login shell for root (same use case). Setting CONFIG_FEATURE_SH_STANDALONE for the static package would probably make sense, so the shell will first use its builtin commands.

• package:
  busybox-1.30.1_1

[CameronNemo]

• username completion
• ash symlink and registering the shell
• unprivileged ping usage: I would rather not set cap_net_raw on the entire busybox binary. Is there some other privilege escalation mechanism that can be used, such as sudo, doas, or a wrapper?
• less more than one line
• static shell builtin preference: could be useful for an emergency shell, but could be confusing in more general usage. Need to think on this request.

#11358

[dbrll]

• Regarding unprivileged ping usage, sudo works (doas probably does too) but isn't very convenient compared to the traditional iputils ping. However a suid bit might be an option after all: https://bugs.archlinux.org/task/25999
  It would require supplying a configuration file in /etc/busybox.conf.

• Also, apparently the busybox package doesn't properly support UTF-8. This can be showed with busybox vi where any special char will be displayed ".." instead.
  The following option should not be set for it to work:

# CONFIG_LOCALE_SUPPORT is not set

• A last thing, there is no PS1 parsing by default, those who have something like "PS1="\w$ " in their .ashrc will just see the literal "\w$" for their prompt. This can be enabled with

CONFIG_FEATURE_EDITING_FANCY_PROMPT

I see no adverse effect setting this option. Sorry for noticing those two minor issues later.

[CameronNemo]

Anything else of interest? Working on this now, hoping to have a PR later.

[schraubenschluessel]

I would love to have a package which bootstraps void with busybox as a base.

[santicalcagno]

Just dumping this here in case that it is useful to someone. I was planning to do it myself but I'm not finding the time lately.

• Maybe checking the diff with Alpine's busybox config would give more insights. Unfortunately there are ~300 different lines: https://www.diffchecker.com/5mTEjCos
• @the-wrench99 that would be base-system-busybox, see base-system-busybox #9191. Personally I'm interested in having it listed too, with alternatives instead of conflicts as @CameronNemo commented there.

[schraubenschluessel]

@santicalcagno We could realize it as a package option, so anyone who wants can build it himself.

[dbrll]

@the-wrench99, so I have successfully replaced GNU Coreutils with busybox, for both the system and initramfs. I am very pleased with the result.

So far I only noticed three minor issues:

• The busybox hwclock lacks an option required at boot so I didn't build it. The regular hwclock should be used.
• Same for psutils, however it's not part of Coreutils so it's no big deal.
• The full console font path should be provided in either rc.conf or ideally in the busybox build options: CONFIG_DEFAULT_SETFONT_DIR="/usr/share/kbd/consolefonts/".

I still have an issue with PAM_SCRIPT but it's probably out of scope since it doesn't ship with the system, and I can work around it.

For those interested in trying this migration, compile busybox with the standalone option (CONFIG_FEATURE_SH_STANDALONE) so it will use its builtin commands instead of the system commands. Then symlink /bin/sh to the newly built busybox, reboot, and test.

If everything works, you can build more applets to check how much of base-system is replaceable with busybox. Alpine has a full busybox base-system so I suspect everything in base-system can eventually be replaced with it.

So I cast my vote to revive the base-system-busybox package. After musl and runit, proposing a busybox base system brings some value to Void for those who favor minimalism and technical simplicity in a distribution.

[SirMetathyst]

Is bringing back the busybox base system still being considered? As @Kehak said, I also favour void Linux because of its minimalism and a busybox system would be awesome. Is there a guide or something to help me do this?

[CameronNemo]

would love to do it, but #15836 and void-linux/xbps#185 are blockers

[jsxof]

I really hope that this feature will be eventually implemented. It'd be amazing to have libressl, runit and busybox working on one system.

[ericonr]

SUID'ing or otherwise adding caps to busybox seems bad. IIRC Alpine carries a patch that moves things around in ping to not require privileges.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[Toromino]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

The issues are still present. 🥴

We could probably copy over the patches that Alpine, Adelie and other Linux distros use.
https://git.adelielinux.org/ska/packages/-/tree/master/legacy/busybox
https://git.alpinelinux.org/aports/tree/main/busybox?h=master

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[ericonr]

At that point they might just as well fork busybox.... That's way too many patches.

[dbrll]

Many of those patches should actually be merged upstream. And those which aren't bugfixes should be allowed to be built as options.

[github-actions]

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

[xplshn]

Seems like the way to go would be to create a PR... Busybox is already provided, we should be alright using all the patches from Alpine, which are small tweaks to make Busybox suitable for general systems and not embedded ones. Also, the busybox package should provide "alternatives" like the ip command, etc.