[PATCH] busybox binary name

[Tito]

On Sunday 06 March 2011 23:58:27 Denys Vlasenko wrote:
> On Sunday 06 March 2011 21:29, Tito wrote:
> > On Sunday 06 March 2011 18:17:56 Denys Vlasenko wrote:
> > > On Sunday 06 March 2011 08:07, Tito wrote:
> > > > > 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?
> > > 
> > > bb_busybox_exec_path is used for re-execution of the busybox.
> > > Since /proc is usually mounted, /proc/self/exe refers
> > > to the file which contains current binary.
> > > 
> > Hi,
> > I see, but I guess this will not work :
> > 
> > 1) in the case of multiple busybox binaries (e.g.: one suid and one not, or base + extra applets)
> 
> Re-execution is used only for NOMMU tricks to create a daemonized child
> (in which case we always re-execute *the same applet*, and having several
> busyboxes is not a problem), and for standalone shell and noexec trick,
> both of which fall back to $PATH searching, meaning they will also
> woth in "multiple busyboxes" setup.

So lets make a little test:

mkdir test
mkdir test/bin
mkdir test/sbin
mkdir test/usr/bin
mkdir test/usr/sbin

compile a static busybox with all commands but without ls
compile a static busybox containing only ls
copy them to test/bin as busybox and busybox2
we do not mount proc on purpose

su
cd test
cd bin 
ln -s busybox bash
cd ..
chroot .
busybox --install -s
busybox2 --install -s
ls
/bin/bash: ls: not found
cd bin
./ls
./ls: not found

from another non chrooted shell

ls
lrwxrwxrwx 1 tito tito       7 2011-03-07 15:08 bash -> busybox
lrwxrwxrwx 1 root root      14 2011-03-07 15:09 ls -> /proc/self/exe

so the shell of our first busybox instance (bash)
calls ls by looking it up on the path as you have said
and founds it as link to /proc/self/exe and therefore
tries to rexec itself as ls rather than the other 
busybox(2) binary containing the ls applet.



> 
> > 2)  or if third party binaries are hosted on the system and call a busybox applet

Let us write a little test program:
-------------------------------------------------------------------------------------
#include <unistd.h>
#include <stdio.h>

int main(int argc, char**argv)
{
	execlp("ls", NULL);
	printf("failed\n");
	return 0;
}
----------------------------------------------------------------------------------------

and copy it to our previous test/bin dir.

-rwxr-xr-x 1 tito tito 568572 2011-03-07 15:18 myprog


and always in our chrooted env:

myprog
failed


> They find busybox via $PATH, not via bb_busybox_exec_path.

Yes they find busybox via $PATH but if --install
is executed without  /proc being mounted
and thus  bb_busybox_exec_path is used 
as fallback value they will find a link
to /proc/self/exe, a link pointing to themselves.
> 
> > This will work ONLY if there is just ONE busybox binary
> > and no other third party program on the system,
> 
> I don't understand. Why do you think so?

See above.
> 
> > therefore it seems to me that sticking to the full
> > path would be the solution that makes
> > Things Work (Tm) always.
> > This /proc/self/exe stuff is also non-portable,
> > so we have to decide if we want to be portable
> > to *bsd/unix/osx/windows/whatever or linux-only.

In my opinion we should at least test if proc is mounted
and /proc/self/exe exists before running --install.

> Then set CONFIG_BUSYBOX_EXEC_PATH the way you want.
> No problem.
> 

I think that rather than setting it to a hardcoded value
it is less error prone to prompt the user for it
when running --install.

Ciao,
Tito