On Mon, Sep 2, 2019 at 2:49 PM Rob Landley <[email protected]> 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 > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
