[PATCH] busybox binary name

[Tito]

On Sunday 06 March 2011 06:04:06 Denys Vlasenko wrote:
> On Saturday 05 March 2011 18:09, Tito wrote:
> > On Saturday 05 March 2011 16:51:11 Tito wrote:
> > > On Wednesday 02 March 2011 02:19:02 Denys Vlasenko wrote:
> > > > On Tuesday 01 March 2011 22:08, Tobias Poschwatta wrote:
> > > > > The attached patch allows to change the name of the main busybox binary
> > > > > to something other than "busybox". This makes it easy to have two or
> > > > > more busybox binaries (different versions, different feature sets, etc.)
> > > > > installed in the same filesystem.
> > > > 
> > > > It is already possible by using a suffix:
> > > > 
> > > > # cp busybox busybox2
> > > > # ./busybox2
> > > > BusyBox v1.19.0.git (2011-03-01 16:23:40 CET) multi-call binary.
> > > > Copyright (C) 1998-2009 Erik Andersen, Rob Landley, Denys Vlasenko
> > > > and others. Licensed under GPLv2.
> > > > See source distribution for full notice.
> > > > 
> > > > Usage: busybox [function] [arguments]...
> > > >    or: busybox --list[-full]
> > > >    or: function [arguments]...
> > > > 
> > > >         BusyBox is a multi-call binary that combines many common Unix
> > > >         utilities into a single executable.  Most people will create a
> > > >         link to busybox for each function they wish to use and BusyBox
> > > >         will act like whatever it was invoked as.
> > > > 
> > > > Currently defined functions:
> > > >         [, [[, acpid, add-shell, addgroup, adduser ...
> > > > 
> > > 
> > > Hi,
> > > while inspecting the behaviour of busybox --install -s in a chroot
> > > environment I've noticed something that looks wrong to me:
> > > 
> > > 
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 addgroup -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 adduser -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 ash -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 base64 -> /proc/self/exe
> > > -rwxr-xr-x 1 0 0 700492 Mar  5 13:55 bash
> > > -rwxr-xr-x 1 0 0 724192 Mar  5 13:56 busybox
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 cat -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 catv -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 chattr -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 chgrp -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 chmod -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 chown -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 cp -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 cpio -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 cttyhack -> /proc/self/exe
> > > lrwxrwxrwx 1 0 0     14 Mar  5 14:02 date -> /proc/self/exe
> > > 
> > > 
> > > all links point to /proc/self/exe as bb_busybox_exec_path is used :
> > > 
> > > config BUSYBOX_EXEC_PATH
> > > 	string "Path to BusyBox executable"
> > > 	default "/proc/self/exe"
> > > 	help
> > > 	  When Busybox applets need to run other busybox applets, BusyBox
> > > 	  sometimes needs to exec() itself. When the /proc filesystem is
> > > 	  mounted, /proc/self/exe always points to the currently running
> > > 	  executable. If you haven't got /proc, set this to wherever you
> > > 	  want to run BusyBox from.
> > > 
> > > This seems not to be a sane default here as
> > > 1) was not able to make this work in a chrooted env
> > > 2) in case of failure  xmalloc_readlink symlinks
> > >     point to /proc/self/exe
> > > 3) it works only if /proc/ is mounted
> > > 
> > > I would suggest rather than doing it automagically
> > > as this setp is done only at setup time (from a known path i suppose)
> > > to enforce that the busybox binary is called on the command line
> > > with the full path, the pros are:
> > > 
> > > 1) no need for /proc
> > > 2) name of busybox could be changed and different busybox
> > >     executables could be used at the same time.
> > > 3) works in my chroot env.
> > > 4) it is simple.
> > > 
> > > 	if (ENABLE_FEATURE_INSTALLER && strcmp(argv[1], "--install") == 0) {
> > > 		int use_symbolic_links = (argv[2] && strcmp(argv[2], "-s") == 0);	
> > > 		if (!strchr(argv[0], '/'))
> > > 			bb_error_msg_and_die("Please call %s with the full path", argv[0]);
> > > 		/* busybox --install [-s] [DIR]: */
> > > 		/* -s: make symlinks */
> > > 		/* DIR: directory to install links to */
> > > 		install_links(argv[0], use_symbolic_links, (argv[3]) ? argv[3] : NULL);
> > > 		return 0;
> > > 	}
> > > 
> > > Hints, critics, improvements are welcome.
> > > Ciao,
> > > Tito
> > > 
> > > 
> > 
> > Minor fix to catch ./busybox.
> > Attached patch v2.
> > 
> > 	if (ENABLE_FEATURE_INSTALLER && strcmp(argv[1], "--install") == 0) {
> > 		int use_symbolic_links = (argv[2] && strcmp(argv[2], "-s") == 0);
> > 		if (strncmp(argv[0], "./", 2) == 0 || !strchr(argv[0], '/'))
> > 			bb_error_msg_and_die("Please call %s with the full path", argv[0]);
> 
> What about ../abc/./def/busybox etc?

Ops, have not tought about it, OTH as I was asking the user
for a full path and It is his responsibility to provide a correct one.

> > 		/* busybox --install [-s] [DIR]: */
> > 		/* -s: make symlinks */
> > 		/* DIR: directory to install links to */
> > 		install_links(argv[0], use_symbolic_links, (argv[3]) ? argv[3] : NULL);
> > 		return 0;
> > 	}
> 
> 
> How about this?
> 
> http://git.busybox.net/busybox/commit/?id=4a2a86d5e7e7bf284a31af604a738dfa1f1a2240
> 

Will fail on ./busybox or bin/busybox, etc

+ if (argv[0][0] == '/')
+ busybox = argv[0];
+ else
+ busybox = bb_busybox_exec_path;

and will set the path to /proc/self/exe
and will not work in the end.
I wonder why should /proc/self/exe be
a sane default?

Ciao,
Tito