FAQ#10 misleading

[an0n981]

Only restricting shell/su doesn't always disable root access. 2 qucick examples: jackpal.androidterm uses a native library and org.adaway uses shell/exec to gain root access

I would do a pull request but GitHub app is not very user friendly

[M66B]

I have improved matching of the sh and su commands and updated the description. Could you be so kind to test this version and let me know of the su and sh are always matched okay?
http://d-h.st/ChR

[an0n981]

Please advise as to how to test this. Google translate refuses to translate Java to English so don't really know what to look for.

[M66B]

Simply by checking if shell/sh, shell/su and shell/exec are triggered with the correct commands.
For example AdAway should show su now instead of exec.
With on demand this is most easily checked, since it shows the command.

[an0n981]

With AdAway it now shows su. However another app com.jrummy.liberty.toolboxpro still shows sh to access root. It also has a lite version if you want to verify this.

[M66B]

What is the command for com.jrummy.liberty.toolboxpro?

[an0n981]

shell/sh at startup

once I actually attempt to do anything in the app (disable a broadcast receiver) then it asks for su

so I'm assuming this actually is correct?

Edit: but that would mean that app is still accessing root via shell on startup

[M66B]

Yes, the su detection is not perfect.
To be sure, check the exact parameter in the usage data.

[an0n981]

for shell/sh parameter sh
for shell/su parameter su

[M66B]

Then it is as good as it can be ;-)