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 _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox