[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [PATCH 1/2] Allow BusyBox to be built without a list of applet names
From:       Jody Lee Bruchon <jody () jodybruchon ! com>
Date:       2016-04-30 14:55:48
Message-ID: 081FA115-1C9B-438B-A664-8ECC59139A3E () jodybruchon ! com
[Download RAW message or body]

On April 30, 2016 10:07:46 AM EDT, James B <jamesbond3142@gmail.com> wrote:

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

On April 30, 2016 9:07:42 AM EDT, Tito <farmatito@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@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.


Why was there a symlink to busybox for a command that it doesn't implement? Why is \
someone calling 'busybox command' for a command that is not ever implemented in \
BusyBox? I understand what you're trying to say, but there are a lot of things that \
would have to be done intentionally to end up running a destructive command in the \
way you're supposing, including an unlikely hash collision that can be checked \
against the entire possible applet list at compile time. If the environment is tight \
enough that this optimization is being enabled, the risk tradeoff is worth it to the \
engineer that is putting it all together.

I'm not advocating for the inclusion of this change. I feel that the added complexity \
negates the minimal gains provided. _______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox


[prev in list] [next in list] [prev in thread] [next in thread]