Quote:
Originally Posted by Lucas Malor
From man env:
PHP Code:
-i, --ignore-environment
start with an empty environment
Maybe busybox on Kobo starts env with -i implicitly? |
Hi Lucas,
That's a good guess, but doesn't make sense ...
The KOBO is only erasing select variables, not all environment variables, so that shouldn't be the problem.
Although, I just tested your idea by doing "busybox sh -i" and "busybox -i sh", and weirdly enough -- NEITHER of them erased all environment variables. The second one is rejected, as it thinks the applet is '-i', and the first one would traditionally cause the shell to be interactive. So -- I don't even know how to pass a '-i' flag to busybox and test your idea... I'll have to read the manual on busybox carefully in a few days.
But-- the problem I've been experiencing is that busybox apps were only erasing variables found in the sanitize list in the source code, the last time I checked.
So, (as an example) if I define a variable called "TEST", that one will not be erased-- but LD_LIBRARY_PATH would be erased.
I also have my doubts that it's busybox itself which is the problem. Because, I don't see how after changing the binary -- that it could still possibly be erasing LD_LIBRARY_PATH. But it does.
It acts a bit like I expect a virus would, eg: the program itself does not have the code, but operates a certain way after being loaded. So -- perhaps busybox is being modified by another program, a kernel driver, or a dynamic library. (?) Makes me suspicious my Kobo has been infected by spyware...
I'll know for sure if the behavior changes in the future, because generally posting that you have found spyware, make the creators of that spyware change the behavior to avoid further detection when other people start discovering it; and then all I need to do is compare the md5 sums to see which binaries were altered.
I cross compiled Python and installed it to do the test with, but it's not python that is causing the issue.
I can run bash shell, or python on the system -- and both of them allow me to inspect system variables.
No variables are ever erased when I run python manually, or bash shell. They were only erased when I run busybox's 'env' program, or sh.
But Note: the cross compilation of Python 2.7.10 (ironically, a bugfix release) is broken on an x86_64 machine and will produce a binary executable that either segfaults, or else is missing a symbol in all the import libraries on the Kobo. SO if you have a 32/64 bit multilibrary PC, you will likely have lots of problems trying to cross compile python 2.7.10 even using Kobo's tools.
Right now I have simply installed a pre-compiled python binary from the Rasperry-PI version 1, Debian distribution. Rasberry Pi Generation 1, uses an older (v6) Arm processor, but old code runs just fine on the Kobo which has a more advanced processor.
I also just bought a second generation Rasberry PI, to compile stuff on for my Kobo since it comes with GCC and does not cross compile but does a true native compile; so the cross compiler bugs in Python shouldn't affect it.
I wrote to the python users group about the issue, but no one there appears to know how to cross compile it either; and so, the only thing left is to contact the maintainers of the C-Python Source code, and ask if they have a way to fix the issue. ( I'll be doing that this week. )