Limit BusyBox applets to /bin and /sbin

RFC

Is it possible to limit BusyBox applets to /bin and /sbin by default?

Goal

Prevent opkg from modifying /usr/bin and /usr/sbin when the user upgrades BusyBox.

Problem

Solution

Related threads

1 Like

maybe...

CONFIG_BUSYBOX_DEFAULT_INSTALL_NO_USR
1 Like

Yep, it looks promising.
I wonder why this is not enabled by default.

removed the solved... looking forward to more input also...

as nobody weighed in yet... i'll throw out some hypothesis;

  • it's a new option?
  • goes against posix / fundamental philosophies?
  • these things were usually application centric... as busy isn't updated too often ( let alone 'upgraded' )... this is a fairly rare event ( thus KISS-ed )?
  • breaks/poses significant risk/obstacle to low level operations ( sysup / do_stage2 etc. )?

it would seem this is not a relevant topic to most with the skills or power to make a difference...

1 Like

BysyBox applets are just symlinks, so it shouldn't really matter where they are located as long as it is within the PATH.

But, I'm afraid this issue may be a bit more complicated:

> for PKG in ip-tiny ip-full busybox; \
> do opkg files ${PKG}; done | grep -e /ip
/usr/libexec/ip-tiny
/usr/libexec/ip-full
/sbin/ip

Thus, isolating BusyBox is not a complete solution.
The best option would be using something like alternatives.

On the other hand, it is still better than the current situation.

The event doesn't happen often, but it's already multiple users who reported the issue.
In my experience, there are usually at least ten times more people who have encountered the problem than reported.
And this is not the first time, the wave of cries floods the forum every time we have a new BusyBox version.

1 Like

i'm trying to track down a post where jow / slh / hnyman? laid out some useful info re: package postinst like scripts... and something about updating all their makefiles... best info on this topic i've seen here...

while i'm looking ... may as well pin some of the more useful... / related posts I come across...
ib sort conflict query
buildroot make selections order issue ~ transient?
related to above
when something core needs to be less core
waxing the shell spot
you [s]scream[/s] stream are another fish kettle

ok... this is the one I was looking for... thank @hnyman :green_heart:

application centric philosophy

nope: it was this one...

guru meditation

1 Like
for this in $(opkg files busybox | grep -vE '(^Pack|^/etc)'); do echo "$this: $(readlink -f $this) $(opkg search $(readlink -f $this) | cut -d' ' -f1)" | grep -v ' busybox$'; done
/sbin/ip: /usr/libexec/ip-full ip-full
/bin/sleep: /usr/bin/gnu-sleep coreutils-sleep
/usr/bin/sort: /usr/bin/gnu-sort coreutils-sort
/usr/bin/cmp: /usr/bin/gnu-cmp diffutils
/usr/bin/top: /etc/custom/busybox.static.4-model-b

Yep, I've already checked that way, but it works only for installed packages and only if they were installed later than busybox, e.g. you are missing ip-tiny.


This whole issue seems to be part of a bigger and more serious problem.

Currently it is not recommended to perform package upgrades.
However, time flies and things change...

High performance network hardware, virtualization and containers are not so rare nowadays.
These use cases have no hardware limitations to perform upgrades.
If OpenWrt cannot provide this functionality, it may eventually lose its position and users.


It looks like there's no much point to keep this thread open.
What should have been said has already been said.
The BusyBox config parameter works around the issue for me well enough.
Probably it's best to continue by opening a ticket on the bug tracker, or contributing the patches directly.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.