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