On Wed, Aug 24, 2016 at 1:25 PM, Bruno Chevalier <[email protected]> wrote: > On 19 August 2016 at 10:53, Denys Vlasenko <[email protected]> wrote: >> >> >> I don't understand what you are trying to achieve by this code. >> If executable can be found in PATH, what are the benefits from >> not running it but running an applet? >> >> This can be confusing to the user. > > > If the executable can be found in PATH, we are going to execute it. > That's the whole point. > > If busybox contains f.e. the nandwrite applet, and the symlink from > nandwrite to busybox is replaced by the actual nandwrite program, we want to > execute the nandwrite program and not the busybox applet.
Ok so far. > If in another case (without reconfiguring busybox) that link is not > overwritten, we want to execute the applet, while still making use of the > NOEXEC trick. I don't like it. A program is found in PATH. Whether it will be executed or not magically depends on where it points to (if it is a symlink). Such behavior is not expected by users. Users do know that shells have builtins and that "echo" may not necessarily run /bin/echo. But this decision is made *statically*. Does not depend on what /bin/echo is. With your patch, it will start depending on that too. > In the current implementation, when you want to make use of the NOEXEC trick > for busybox applets, you automatically have to accept that your PATH won't > be searched for programs with that applet's name. Yes. I understand that you don't like it and want to use external tools. Will it work for you to simply unset FEATURE_SH_STANDALONE? FEATURE_SH_STANDALONE is meant for situations where user doesn't want to be bothered by the need to create /bin/foo -> /bin/busybox links, IOW: a very minimalistic system. Your situation is clearly different. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
