7

I can get a root prompt in the terminal by running one exploits documented elsewhere. (e.g. here: http://wiki.cyanogenmod.com/wiki/Motorola_Droid_2_Global:_Full_Update_Guide)

At this point, I can install the "su" binary and give it permissions 4755. This should allow anyone to execute it, and since the owner of the binary is "root" and the sticky bit is set, I should become root. But I apparently have no way of un-become root from the terminal short of rebooting. But, after I reboot, then I can't seem to become root using 'su'.

$ ls -l /system/bin/su
-rwsr-xr-x root    app_101    26234 2012-07-09 15:00 su

Ok, the permissions look fine, should I should be able to run it to become root, but only in this particular invocation of the terminal.

$ /system/bin/su
Permission denied

It also fails if i specify the command to run as root, or with any other arguments:

$ /system/bin/su /system/bin/sh
Permission denied

Why? Is there some other mechanism at work? I don't want to install Superuser.apk, because I just want a way that I can temporarily get a root shell if needed, for instance to delete unwanted files manually. Besides, Superuser.apk relies on the su binary anyway, so it must have some way of calling it, so why can't I replicate that in the terminal?

Edit: I had another thought, so I tried copying /bin/sh to another locattion and made it suid root. But while I can execute the new binary, it doesn't give me root. Is Android doing something tricky/different with suid that regular Linux does not do?

2
  • 1
    Having an unprotected 'su' on the device is pretty risky, as anything that attempts to use it will get it without any of the user confirmation that things like that superuser app try to add as a gateway. Commented Jul 10, 2012 at 5:30
  • Right, well... I was trying to plan ahead. Wasn't sure how a subsequent update would try to get rid of su, so I put it in a bunch of difference places with different names. Turns out the update removes the sticky bit, and I can't run suid from places other than system. Ah well.
    – Michael
    Commented Jul 10, 2012 at 5:56

3 Answers 3

6

The clue is in the owner/group id...

$ ls -l /system/bin/su
-rwsr-xr-x root    app_101    26234 2012-07-09 15:00 su

Notice the group id is set to 'app_101', that should be 'root', but then again, you need the busybox binary (which is part of the SuperUser.apk binary, when installed, it copies the relevant said binary into /system/xbin) in order to be able to chown it.

1
  • Yes, this would be a problem Ultimately busybox is not needed as stock android chown can change the group as well, using chown user.group filename (at least from Froyo-ICS) Commented Jul 10, 2012 at 5:23
1

Try adding the -c option. e.g.

su -c sh

or

 su -c 'echo bogus'

(for more arguments)

0

A bit more digging and I think I have turned up the answer. The reason it is not working is because the Terminal app does not request super-user permission in its manifest, e.g.:

<uses-permission android:name="android.permission.ACCESS_SUPERUSER"/>

This extra layer of security appears to be because the terminal application is a java application, although it does a good job of hiding it. The Superuser appears to shim things somehow so java apps can get this permission, even if they didn't know they needed it when they were created.

1
  • 2
    ACCESS_SUPERUSER permission is not connected with your problem
    – janot
    Commented Oct 5, 2014 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .