[patch] proposed change to busybox option parsing.

[Rob Landley]

On Monday 05 September 2005 06:44, Aurelien Jacobs wrote:
> > You can also edit the source code if you really really really really
> > really  want busybox to be called "bb", but unless you can explain
> > what possible  advantage doing that has there's no point in us adding
> > a gratuitous config  option that has no purpose.
>
> I have no reason to rename busybox to bb, and indeed I don't do it.
> That's just, that I dislike reducing users freedom (to rename busybox
> to whatever they want) when there is not a very good reason for it.
> I didn't found any good reason, but it seems I had overlooked a few
> "details".

If you run a privilidged script (shell-based web server cgi is the obvious red 
flag but there's plenty of others; dhcp scripts, something triggered by dbus, 
who knows what embedded systems have) that calls something innocuous like 
"cmp", and you upgrade to a version of busybox that doesn't have that built 
in, old symlinks would still be there from the previous install and your 
script might not actually fail in an obvious enough way for this to be 
spotted quickly.  If the user can supply the first argument to the 
nonexistent command, it can become "rm" or "cat" or who knows what.

I don't know what all the potential security implications of this are, but 
definitely it's a sharp pointy bit we should file smooth.  And that means 
calling busybox under an arbitrary name should _not_ give you the 
multiplexing behavior.

> > It's built-in to busybox that the names the applets are invoked under
> > determines how they behave.  The "busybox" applet is not special in
> > this  regard.
>
> Hum... really ? But you still want to be able to run busybox-new for
> example ? That would mean that we could also expect ls-new to work ?

I personally didn't want to, no.  But Erik came down firmly on the side of 
being able to do this, and he's the maintainer, so...

> So the only really proper solution would be to build a list of all
> the possible applets in busybox (even the one which are not built-in)
> to really detect if the users tried to run an applet or the busybox
> binary itself. But this would enlarge busybox which is very bad and
> certainly not acceptable.
>
> So finally it seems that the busybox* hack is the more reasonable
> solution.

I think so.

> Aurel

Rob