View Single Post
Posts: 268 | Thanked: 1,053 times | Joined on May 2010 @ The Netherlands
#144
Originally Posted by vi_ View Post
I have found a bug in BB-P. In the last version of BackupMenu Robbie was kind enough to add a framebuffer console. This allows you to access the console through BM. One problem...

Without BB-P it works fine.

With BB-P it gets as far as asking for your username then crashes back to the BM main menu when you press return (to enter your username). It gives the error: "applet not found". This is the BB error for when a BB applet has been called but does not exist. Useually the name of the erroneously called applet is given in the error (foobar: applet not found). With BB-P installed there is no name supplied.

I can confirm it is the BB-P package as if I remove it (apt-get uninstall) then try root console again it works, re-install, it fails.
Thanks for reporting, I've just verified the bug on my device.
What surprises me is that you're the first one to report this, while the latest BackupMenu has been released in back in July.

Originally Posted by vi_ View Post
The last line in BM when console is selected is:

Code:
 busybox getty 115200 tty1 sh
I assume BB then has to run 'login' or 'logon' or whatever and it is somehow failing. I don't really know my understanding of how a new shell is spawned is a bit...uh...thin.
Yep, the login applet seems to be the culprit. BackupMenu assumes that all utilities are provided by /bin/busybox. This is true for the default busybox setup, but not for busybox-power. Coincidentally, the very same 'issue' as described one page back in this thread is happening, only now with the login applet instead of ping: login is an applet that requires the SUID bit to be set to work for non-root users. Therefore, the login applet has been split to /bin/busybox_root.

Originally Posted by vi_ View Post
The more I think about it the more i think this implies there is something with BB-P 'getty' applet.

iDont, how is BB-P installed these days? Is the original binary still there? Can I change my 'getty' symlink to point to the old binary to test this?


MOAR!

The more I look, the more I see getty has been changed from v1.15->v1.19.

Looking at the source they both #include the exact same files so potentially getty.c v1.15 could be substituted for getty.c v1.19. While it may work it doesn't explain why there is an issue (assuming it is even getty that is the problem) after all, all the changes to getty.c have been simple bug fixes right? RIGHT??
Eager to see this bug fixed no? Assuming the missing login applet indeed is the issue, then the solution is simple, either:
a) Pull login (and all other "SUID applets") back into busybox from busybox_root, or
b) Change BackupMenu's logic to symlink busybox' utilities in its own root like how they're symlinked in the default filesystem (which happens to be to two different binaries when using busybox-power -> busybox and busybox_root)

I think it's best to go with solution A since this reduces maintenance and makes things less confusing for users. The only downside is that when we set the SUID bit on /bin/busybox, well, a lot of utilities (i.e. cp) effectively have the SUID bit set. However, BusyBox can be configured to automatically drop privileges for applets that do not require the SUID bit to be set. As stated in a previous post: there were some issues with this feature in the past, but it seems to work as expected nowadays.

If anyone has a problem with the above solution, please let me know. Otherwise expect busybox-power 1.19.3power2 to hit the repositories tomorrow's evening.

P.s. RE how busybox-power is installed these days: have a look in /opt/busybox-power I would say. The deb installs its content to that location, after which install-binary.sh takes over to symlink etcetera. Be sure not to mess anything up in that folder though, for obvious reasons
 

The Following 7 Users Say Thank You to iDont For This Useful Post: