isRootAvailable uses SU access while it should not?

[GoogleCodeExporter]

What steps will reproduce the problem?
1. call "RootTools.isRootAvailable()
2. SuperUser apk asks for SU permission
3.

What is the expected output? What do you see instead?
It should only show if root is available, however it somehow triggers root 
access.

What version of the product are you using? On what operating system?
2.6

Please provide any additional information below.

According to the docs it should not try to use root when that action is 
performed, but it does somehow.

Original issue reported on code.google.com by goo...@umito.nl on 8 Apr 2013 at 7:58

[GoogleCodeExporter]

Can you show me where it states that it should no try to use root? (link 
perhaps?)

Original comment by Stericso...@gmail.com on 8 Apr 2013 at 8:15

[GoogleCodeExporter]

https://code.google.com/p/roottools/wiki/Usage

Checking for su
su is the binary that is used to grant root access. It being on the phone is 
usually a good sign that the phone is rooted. You can check for the su binary 
like so:

if (RootTools.isRootAvailable()) {
    // su exists, do something
} else {
    // do something else
}
Note that this only check that su exists. A more complete check can also be run:

if (RootTools.isAccessGiven()) {
    // your app has been granted root access
}
RootTools.isAccessGiven() not only checks that a device is rooted, it also 
calls su for your app, requests permission, and returns true if your app was 
successfully granted root permissions. This can be used as the first check in 
your app to make sure that you will be granted access when you need it.

Original comment by goo...@umito.nl on 8 Apr 2013 at 8:27

[GoogleCodeExporter]

It is usefull to have, since I want to disable some functionality based on root 
existing or not. I don't want to use that root access until a user chooses a 
action that needs it.

Original comment by goo...@umito.nl on 8 Apr 2013 at 8:28

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I see...

So... isRootAvailable does not guarantee that root will not be called, this is 
because the underlying method that is used to check for the binary will use 
Root if the first attempt to find the binary without root fails. This is needed 
because the binary could be hiding in places that require root access to search.

heh, I realize it is a bit strange to invoke root in the search for the su 
binary because  obviously if root access is granted than the binary does exist 
but it gets the job done and the underlying method is used to search for things 
other than the root binary.

With all of that being said I can make it so that the underlying functionality 
does not search for the su binary with root access if it does not find it on 
its first pass. 

However, there is also another issue, the method will only open a shell if one 
is not already opened. This means that if a root shell is opened then the 
method would search with this root shell and would utilize su.

I'm certain that the latter is not of concern to you but I thought I would 
mention it. 

Finally, I would like to point out that without using root access there are 
places that you will not be able to search for the su binary, so the su binary 
could very well exist and you would be unaware of it. This sounds like a bad 
thing for what you are doing. Sadly, there is nothing that can be done about it.

I will add the ability to do what I mentioned above with the limitations that I 
specified above.

Original comment by Stericso...@gmail.com on 8 Apr 2013 at 8:48

[GoogleCodeExporter]

Ok, I understand.

However, could you explain how it can be possible that you can't see the su 
binary, but do access it?  Is that not a paradox?

Original comment by dexplore...@gmail.com on 8 Apr 2013 at 9:07

[GoogleCodeExporter]

It's not a paradox, it comes down to permissions.

Your application may not have the permissions to access the directory that the 
su binary is located while something else may have the permissions to access 
the location that the binary is located. 

Also, keep in mind that the method used in RootTools to locate the su binary 
only checks the paths declared in the PATH environment variable for the binary, 
it won't check paths or location that are not set within the environment 
variable PATH. RootTools doesn't do this because it is a rare occurrence that 
any binary we are searching for is outside of the location specified with the 
PATH environment variable.

Original comment by Stericso...@gmail.com on 8 Apr 2013 at 9:23

[GoogleCodeExporter]

I too fail to see why you need to elevate privileges to detect presence of the 
su binary. The only requirement is being able to traverse parent directories 
(ie. the executable bit needs to be set on all parent directories).

Although you cannot list a directory which is not readable, a call to 
stat("/unreadable/su") will succeed.

Do you have a counterexample?

Unrelated: the exists() function is prone to command injection via the file 
name 
parameter.

(Landed here after trying to figure why the application of a major bank asked 
for root access - turns out it calls isRootAvailable)

Original comment by j.de.g...@gmail.com on 13 Sep 2013 at 12:58

[GoogleCodeExporter]

Well, that is a neat trick with stat :) I will look into using that to 
alleviate this issue :)

Original comment by Stericso...@gmail.com on 13 Sep 2013 at 1:44

[GoogleCodeExporter]

As a side note, what bank is using Roottools?

Original comment by Stericso...@gmail.com on 13 Sep 2013 at 5:22

[GoogleCodeExporter]

I guess it's ABN AMRO (Dutch)
http://tweakers.net/nieuws/91285/abn-amro-app-voor-android-vraagt-per-abuis-om-r
oot-toegang.html

Original comment by goo...@umito.nl on 13 Sep 2013 at 6:48

[GoogleCodeExporter]

Looking into using stat it has become apparent to me that this might not be a 
viable solution to this problem since stat is not available on all devices. 
Currently it looks like stat is only available on Android devices if Busybox is 
installed on the device. 

I will add the ability to use this binary when available but it will not be a 
full solution to this problem.

Original comment by Stericso...@gmail.com on 7 Oct 2013 at 2:06