[Toybox] Toybox Installer/setup routine?

[Rob Landley]

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."

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.

> 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.

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.

> 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...)

Rob