[Toybox] Toybox Installer/setup routine?

[scsijon]

On 03/09/19 07:50, Rob Landley wrote:
> 
> 
> On 9/1/19 6:22 PM, scsijon wrote:
>> This may be a can of worms or off-topic but...
>>
>> I was wondering if Toybox should/could have an inbuilt installer/setup routine
>> of some sort and how are others handling this retro-fit problem!
> 
> "When I download toybox as a normal user, it doesn't run as root. I don't have
> the root password. Toybox should include some sort of installer to give me root
> access when run as a normal user."
> 
N o, i'm coming from Linux in general, not android specific, also the 
version I use (puppylinux) is the user as root.

> Um... how?
> 
>> I can only talk from the systems i've used in the past, but adding a new build
>> of toybox to a system where busybox resides, or adding where a full version
>> command still needs to exist, 'can be a real pain in the neck'.
> 
> Yes, because you have to root your device.
> 
> As Elliott and I were just discussing, the selinux annotations to give toybox
> the capability to read /proc and such are written by AOSP when the filesystem
> image is created. Said filesystem is just a normal file until it's flashed onto
> a device, it's like writing out a tarball containing files belonging to root.
> That doesn't mean you have permissions to extract it and create files belonging
> to root on that host.
> 
> It's like genext2fs having a -D option so you can tell it to create /dev nodes
> in the new filesystem, because if your build isn't running as root you can't
> mknod things for it to package up. Similarly, Linux's usr/gen_init_cpio.c takes
> an input file describing the metadata of the files it should package up, so you
> can have them belong to root or include dev nodes you can't create on the host.
> There's a gen_initramfs_list.sh tha reads a directory and describes it in this
> format, but you then append stuff. (My old build used to do this, ala
> https://github.com/landley/aboriginal/blob/master/sources/functions.sh#L415 but
> mkroot uses initmpfs instead.)
> 
>> I admit that in
>> most cases where i've added it, it's been the need to add a switch (command
>> -switch) to do something that BB doesn't but toybox does/can, and the
>> consideration of adding a full command isn't always effective, with the rest of
>> toybox being considered 'jam on the bread'.
> 
> I don't understand what you mean by this paragraph.
> 
Which part? The first is that toybox supplies an extra switch that is 
usefull and that the full command supplies to much. The 'jam on the 
bread' means extras gained by association rather than requested (whether 
used or not is moot).

>> What i'd like to be able to do something like this (as an example)>
>>   install the toybox-x86-64 binary into /bin >
>>   run  the command 'toybox-x86-64 -setup>
> 
> You want a "crack root" installer for Android. I've seen a bunch of youtube
> videos about rooting your phone but they all boil down to "sideload this magic
> binary onto your phone and trust it's not installing a rootkit", which is a bit
> of an issue.
> 
Once again, not using it with Android.

> The official way to unlock your bootloader lets you reflash it with a brand new
> image, which means I have to build AOSP and reformat my phone in order to get
> that kind of access, and it's always been too much of a production. I keep
> meaning to do it with my _old_ phones, but I run them into the ground before
> replacing them and then they're not much fun to play with anymore. (My nexus 5
> needs an external battery strapped to it at all times or it powers down after 5
> minutes. Plus I moved the data plan over to the new phone so it would only work
> via wireless anyway.)
> 
>>   >this causes toybox-x86-64 to create the /bin/toybox command link plus all the
>> internal toybox command links in their correct directories, renaming any busybox
>> command links already installed from command to command-BB(, so I can still run
>> them when needed for some reason) i.e. /bin/cksum from busybox becomes cksum-BB
>> by default;
> 
> Even doing that on Linux requires root access to write into /bin.
> 
>>> and where it's a full command it's replacing (not busybox version), it renames
>> the full command as command-FULL so it's also still available  or can be
>> manually changed back when/if needed.
> 
> Just install into $HOME/toybox and add that to the start of the $PATH? Those
> commands would then be found first.

A possability, but it doesn't follow what were doing now with commands, 
where their either in /bin or /usr/bin, I am very reluctant to be forced 
to do this as I don't want to change the current process procedures we 
all use for just one package.
> 
>> I'm not sure it's that hard, as I think it would be mainly renaming busybox
>> links to -BB and full commands to -FULL when doing the install routine as far as
>> the linux community is concerned, and i'm sure enh and others will be able to
>> comment with equivalents relative to the macOS, android, ASOP and other systems
>> your installed into (like that ibm-fuji maintenance timeslot).
> 
> If somebody wants to make an installer for new toybox versions, have at.
> (Although the above "install somewhere and put it at the start of the $PATH"
> seems obvious for everything except /bin/sh?)
> 
> Trying to coexist with an aftermarket busybox install on the same system is not
> hugely interesting to me. _Replacing_ the need for busybox is interesting. (And
> really, you can do a busybox install in $HOME/busybox and then
> PATH=$HOME/toybox:$HOME/busybox:$PATH and it'll fall back in sequence without
> the rest of the system having to care? I dunno how to set $PATH globally for all
> processes (it would be something in init) but that's the majority of what your
> "installer" would have to do. Modulo selinux annotations to make ps work and
> such. :)
> 
>> Currently I've been doing this manually when building a new pet (our install
>> packages for puppylinux), and of course this is time consuming and not just for
>> me, which was why I was wondering what others are doing about this problem, and
>> if there was the possability of adding an inbuilt automatic installer/setup
>> routine, at least to deal with the busybox commands, I don't want to lose them
>> totally, I just don't want them to be used by default after i've installed
>> toybox unless there is a serious reason to go backwards to them.
> 
> Which busybox commands do you miss that aren't in toybox? I should add them to
> the roadmap. (Keep in mind there's a nonzero chance I wrote them to begin with.
> Although less so these days because I went through most of that already...)
> 
I haven't looked into this lately, there are a few we use, ?is your 
roadmap up to date, I shall do a comparison check with what we use, and 
reply about this then.

> Rob
>