[PATCH 1/2] Allow BusyBox to be built without a list of applet names

[James B]

On Sat, 30 Apr 2016 09:36:02 -0400
Jody Lee Bruchon <jody at jodybruchon.com> wrote:

> On April 30, 2016 9:07:42 AM EDT, Tito <farmatito at tiscali.it> wrote:
> >
> >
> >On 04/30/2016 02:58 PM, Jody Lee Bruchon wrote:
> >> On April 30, 2016 8:39:24 AM EDT, Andreas Oberritter
> ><obi at opendreambox.org> wrote:
> >>> On 30.04.2016 09:16, Laurent Bercot wrote:
> >>>
> >>> Even worse, consider a busybox binary that someone expects to
> >contain a
> >>> real command like cat or hexdump, which it doesn't. The colliding
> >hash
> >>> of this command could map to a command that accepts the same
> >>> command-line arguments but destroys data, like mkfs.* or rm.
> >>>
> 
> It doesn't matter. If the user is throwing arbitrary command names at BusyBox, the user deserves whatever they get as a result. 

Ummm, no. If a program isn't expected to destroy data (like "dd" or "mkfs" do), then it should never fail in a way to destroy data. Somebody who accidentally calls "busybox get-some-status /dev/sdb" won't expect that it will end up mkfs-ing this disk, if this "get-some-status" command is not implemented.

> It is not the job of the program to keep the user from abusing it and being bitten as a result. 

It is not. But a simple user failure (specifying a command name that does not exist) should make a program to fail catastrophically.

>>> Still even worse, without the list of applet names included in the
>>> binary, you can't make sure that the applet you're calling actually
>>> exists without dissecting the binary.
>>>

Agreed on this point. Applet names are important.

I vote against this change. The savings are not worth the benefit and the risk.

James