[PATCH] busybox binary name

Tito farmatito at tiscali.it
Sun Mar 6 20:29:39 UTC 2011


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)
2)  or if third party binaries are hosted on the system and call a busybox applet

This will work ONLY if there is just ONE busybox binary
and no other third party program on the system,
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.

Just my 2 cents.

Ciao,
Tito


More information about the busybox mailing list