On 10/20/14 01:50, Isaac Dunham wrote:
> On Mon, Oct 20, 2014 at 01:17:44PM +1100, scsijon wrote:
>> I was wondering if toybox 'could / would be able to' have an auto tool built
>> into it. I'm not a coder, so can't do it, but....
>>
>> Along the line of:
>> --
>> If toybox had the command 'siliswap' built into it, but it's inbuilt
>> siliswap was a subset of the full 'siliswap' command and it's complete set
>> of switches, as for most people and programs it doesn't need the others.
>>
>> If at a later stage, the user needs to install the full 'siliswap' package
>> because they need to use switches that are not built into toybox's
>> 'siliswap' then toybox's 'siliswap' knows to pass the request onto the full
>> siliswap instead of dealing with it itself.
>> --
>> Not sure if it could be added without a shell file though and i'd prefer not
>> to add to the default set. ?or could these be created automatically when
>> toybox is first run, against all inbuilt packages, or manually with a toybox
>> -cfg command).
>>
>> And of course, toybox doesn't have or needs siliswap (it's a very old IBM
>> Mainframe silo interface command), i'm not sure it is even used anymore.
>
>
> 1. Rob keeps talking about simplicity...this doesn't sound very simple.
> It also doesn't sound small--which defeats the point of implementing a
> subset.
A lot of simplicity is how you look at the problem. :)
In this case, xexec() tries the builtin version, then falls back to
exec. If you add a path to your command, it never tries the builtin
version. So "/bin/echo" will always try to exec. That's the current
behavior.
When execing, the symlinks can be replaced after the fact. Even if
"echo" is built into toybox, if /bin/echo isn't a symlink pointing to
toybox then running it will run something else. You can delete the old
symlink and replace it with whatever you want to add to the system.
(This flexibility is intentional, and again is the current behavior.)
You can even have different symlinks pointing to different binaries: I
have a vague todo item to add something like "make suidconfig" and "make
nosuidconfig" that lets you build all the commands that require the suid
bit, and build all the commands that do _not_ require the suid bit. Then
you could break your toybox binary into two binaries, one with the suid
bit and one without it, so commands that don't require suid root don't
start with it. (You shouldn't need to do that, but it makes some people
more comfortable. You can do it now, but have to set up the two configs
by hand with menuconfig.)
> 3. My understanding is that the simpler version of this would basically
> be "search $PATH for a command that doesn't point to toybox if we don't
> handle all the options" (called from get_optflags()?).
> This means that for each element in $PATH, we look for an executable file
> named like $0, check for hard and soft links to the running binary,
> and soft links to a "toybox..." binary.
It sounds like the requested _new_ behavior is to have toybox notice
when exec out of the $PATH wouldn't reenter this toybox binary. And all
ou need for that is a new config symbol CFG_TOYBOX_NORECURSE (defaulting
to off) and then a one line change:
--- a/lib/xwrap.c Sun Oct 19 12:08:25 2014 -0500
+++ b/lib/xwrap.c Mon Oct 20 11:43:21 2014 -0500
@@ -137,7 +137,7 @@
// with a path isn't a builtin, so /bin/sh won't match the builtin sh.
void xexec(char **argv)
{
- if (CFG_TOYBOX) toy_exec(argv);
+ if (CFG_TOYBOX && !CFG_TOYBOX_NORECURSE) toy_exec(argv);
execvp(argv[0], argv);
perror_exit("exec %s", argv[0]);
Yeah we could do "which command" and then stat it and /proc/self/exe and
compare the dev and inode fields to check that it's the same file, or
try various more complicated optimizations. But why bother?
toybox_main() is already calling toy_exec() directly. If you don't want
to recurse internally, don't. This disables an optimization but
otherwise works just fine.
Rob
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
