[Toybox] Toybox Installer/setup routine?

[enh]

On Mon, Sep 2, 2019 at 2:49 PM Rob Landley <rob at landley.net> 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."
>
> 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.

yeah, that's what i did to run the toybox tests on jellybean: dumped
all the symlinks into /data/local/tmp/toybox and then modified $PATH.
note that the suggested command in `toybox --help` isn't helpful
because it's all about /usr/bin and so on... it might be useful to
have a one-liner for "build me a directory of symlinks right here".

> > 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net