FORUMS
Remove All Ads from XDA
H10 Turbo

[DEV GUIDE][2016.12.22] How-To SU

11,225 posts
Thanks Meter: 86,733
 
By Chainfire, Senior Moderator / Senior Recognized Developer - Where is my shirt? on 29th October 2012, 08:38 PM
Post Reply Email Thread
7th October 2014, 09:58 PM |#41  
Inactive Recognized Developer
Flag Ottawa/Gatineau, Canada
Thanks Meter: 4,160
 
Donate to Me
More
Quote:
Originally Posted by andQlimax

/data/data/com.andqlimax.pushfixer/sqlite3: can't execute: Permission denied

Android L does not allow executing binaries from the /data partition .

You have to remount /system as RW and copy it to /system/bin or another /system directory.

This works on the Android L preview. On some Android L releases to come, you may not be able to remount /system and will have to copy files from recovery.
 
 
7th October 2014, 11:03 PM |#42  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,733
 
Donate to Me
More
Quote:
Originally Posted by andQlimax

Today I got some free time and I was trying again to make my root app to work on android L, but I still didn't managed it.
Following the error that I get:

Code:
10-07 21:35:57.569    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU -V%] START
10-07 21:35:57.584    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU -V%] END
10-07 21:35:57.584    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU -V%] START
10-07 21:35:57.594    6429-6620/? D/libsuperuser﹕ [libsuperuser][O][SU -V-] 2.02:SUPERSU
10-07 21:35:57.599    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU -V%] END
10-07 21:35:57.599    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU%] START
10-07 21:35:57.608    6429-6625/? D/libsuperuser﹕ [libsuperuser][O][SU -V-] 202
10-07 21:35:57.614    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU+] /data/data/com.andqlimax.pushfixer/sqlite3 /data/data/com.google.android.gsf/databases/gservices.db " < ... snip ... > ";
10-07 21:35:57.609    6632-6632/? I/auditd﹕ type=1400 audit(0.0:332): avc:  denied  { sys_ptrace } for  comm="daemonsu" capability=19  scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=capability
10-07 21:35:57.609    6635-6635/? I/auditd﹕ type=1400 audit(0.0:333): avc:  denied  { sys_ptrace } for  comm="daemonsu" capability=19  scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=capability
10-07 21:35:57.609    6635-6635/? I/auditd﹕ type=1400 audit(0.0:334): avc:  denied  { sys_ptrace } for  comm="daemonsu" capability=19  scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=capability
10-07 21:35:57.609    6635-6635/? I/auditd﹕ type=1400 audit(0.0:335): avc:  denied  { sys_ptrace } for  comm="daemonsu" capability=19  scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=capability
10-07 21:35:57.619    6635-6635/? I/auditd﹕ type=1400 audit(0.0:336): avc:  denied  { execute } for  comm="tmp-mksh" name="sqlite3" dev="mmcblk0p28" ino=1426546 scontext=u:r:init:s0 tcontext=u:object_r:app_data_file:s0 tclass=file
10-07 21:35:57.628    6429-6631/? D/libsuperuser﹕ [libsuperuser][O][SU*] tmp-mksh: <stdin>[7]: /data/data/com.andqlimax.pushfixer/sqlite3: can't execute: Permission denied
10-07 21:35:57.630    6429-6616/? D/libsuperuser﹕ [libsuperuser][C][SU%] END
Code:
root@hammerhead:/data/data/com.andqlimax.pushfixer # ls -l                     
drwxrwx--x u0_a84   u0_a84            2014-10-07 21:42 cache
lrwxrwxrwx install  install           2014-10-07 21:41 lib -> /data/app-lib/com.andqlimax.pushfixer-1
drwxrwx--x u0_a84   u0_a84            2014-10-07 21:42 shared_prefs
-rwxr-xr-x u0_a84   u0_a84     316031 2014-10-07 21:42 sqlite3
root@hammerhead:/data/data/com.andqlimax.pushfixer #
@Chainfire any ideas would be appreciated. I can't figure out what I'm doing wrong.

Apart from your guide, I didn't find to much around and lately I'm not following to much the "root scene" around android L, so maybe I'm missing something.
Thanks for your time

Quote:
Originally Posted by mikereidis

Android L does not allow executing binaries from the /data partition .

You have to remount /system as RW and copy it to /system/bin or another /system directory.

This works on the Android L preview. On some Android L releases to come, you may not be able to remount /system and will have to copy files from recovery.

Latest AOSP and L preview are odd ducks out. My How-To SU guide describes how to get around the issue by switch for example to the system_server or system_app contexts, to be able to execute apps from /data. See the --context parameter of su.

However, to be perfectly honest, if you're not done yet porting to L preview, I'd hold off until L retail is released (which should be in a few weeks), and then wait for the first SuperSU release after that. The latest SuperSU beta versions already have a new way of patching into these new builds that may take care of the bulk of the issues (such as the one you are having) for most root apps. These are not 100% complete solutions for all apps, but it goes a loooong way. The question is if this method will still work on L retail. But if it does, it will all be backported down to 4.2.2, so all SELinux enforcing Android roots will behave the same again. So right now, all is pretty much in limbo. There are some tricky ways to get things to work, but in a few weeks all may be a significantly easier, so spending too much time on it now would be a waste.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
8th October 2014, 12:02 AM |#43  
Inactive Recognized Developer
Flag Ottawa/Gatineau, Canada
Thanks Meter: 4,160
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

However, to be perfectly honest, if you're not done yet porting to L preview, I'd hold off until L retail is released (which should be in a few weeks), and then wait for the first SuperSU release after that. The latest SuperSU beta versions already have a new way of patching into these new builds that may take care of the bulk of the issues (such as the one you are having) for most root apps. These are not 100% complete solutions for all apps, but it goes a loooong way. The question is if this method will still work on L retail. But if it does, it will all be backported down to 4.2.2, so all SELinux enforcing Android roots will behave the same again. So right now, all is pretty much in limbo. There are some tricky ways to get things to work, but in a few weeks all may be a significantly easier, so spending too much time on it now would be a waste.

I figure the "writing is on the wall" regarding Android security getting tighter and tighter as time goes forward. When chmod is insufficient to get app process access to /dev/snd/*. /dev/ttyHS0. /dev/radio0 etc. I have to try a new approach.

So I've re-architected my root radio app to do all SU/root stuff from a daemon lauched with SU. This has benefits for speed and minimizing bugs and fancy code too. I'm guessing this will fix some Knox issues too.

Having a few months of warning was a welcome move by Google. But I think there will be a constant stream of security tightening ahead and sometimes drastic re-architectures are needed.
8th October 2014, 09:08 AM |#44  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,733
 
Donate to Me
More
Quote:
Originally Posted by mikereidis

I figure the "writing is on the wall" regarding Android security getting tighter and tighter as time goes forward. When chmod is insufficient to get app process access to /dev/snd/*. /dev/ttyHS0. /dev/radio0 etc. I have to try a new approach.

So I've re-architected my root radio app to do all SU/root stuff from a daemon lauched with SU. This has benefits for speed and minimizing bugs and fancy code too. I'm guessing this will fix some Knox issues too.

Having a few months of warning was a welcome move by Google. But I think there will be a constant stream of security tightening ahead and sometimes drastic re-architectures are needed.

Well, if you have a Nexus device, building AOSP from source today will pretty much show you what security will be like on L retail. It is indeed significantly tighter than L preview.
The Following User Says Thank You to Chainfire For This Useful Post: [ View ]
8th October 2014, 07:17 PM |#45  
andQlimax's Avatar
Senior Member
Flag Rome
Thanks Meter: 996
 
Donate to Me
More
Quote:
Originally Posted by mikereidis

Android L does not allow executing binaries from the /data partition .

You have to remount /system as RW and copy it to /system/bin or another /system directory.

This works on the Android L preview. On some Android L releases to come, you may not be able to remount /system and will have to copy files from recovery.

Yes, I know that but like chainfire said, switching context should workaround that problem.

Quote:
Originally Posted by Chainfire

Latest AOSP and L preview are odd ducks out. My How-To SU guide describes how to get around the issue by switch for example to the system_server or system_app contexts, to be able to execute apps from /data. See the --context parameter of su.

However, to be perfectly honest, if you're not done yet porting to L preview, I'd hold off until L retail is released (which should be in a few weeks), and then wait for the first SuperSU release after that. The latest SuperSU beta versions already have a new way of patching into these new builds that may take care of the bulk of the issues (such as the one you are having) for most root apps. These are not 100% complete solutions for all apps, but it goes a loooong way. The question is if this method will still work on L retail. But if it does, it will all be backported down to 4.2.2, so all SELinux enforcing Android roots will behave the same again. So right now, all is pretty much in limbo. There are some tricky ways to get things to work, but in a few weeks all may be a significantly easier, so spending too much time on it now would be a waste.

I'm already using context parameter, I tried switching to almost all contexts in your guide ( not sure, will check again) , but always get the same error.
I will do some other tests and maybe I will also follow your advise to wait couple weeks and see how things evolve.

Thanks for your time and work
27th October 2014, 09:14 AM |#46  
Junior Member
Thanks Meter: 0
 
More
i've read your blog "How-To SU", the libsuperuser_example app didn't work in my Nexus 7. Should i replace the origin su binary with ChainsDD's su binary? But i need to root. Did i make something wrong? Please hlp
15th November 2014, 11:39 PM |#47  
Flyview's Avatar
Senior Member
Flag Toronto/San Diego
Thanks Meter: 1,483
 
More
Hi Chainfire!

I've been using your libsuperuser in my app to run some root commands. For example:

Quote:

rootCommand(new String[]{
"settings put global airplane_mode_radios " + Settings.Global.RADIO_CELL,
"settings put global airplane_mode_on " + (enabled ? 0 : 1),
"am broadcast -a android.intent.action.AIRPLANE_MODE --ez state " + !enabled});
"settings put global airplane_mode_radios " + originalAirplaneModeRadios});

where rootCommand() is :

Quote:

public static void rootCommand(final String[] commands) {
new Thread(new Runnable() {

@override
public void run() {
Shell.SU.run(commands);
}
}).start();
}

However, starting on Android Lollipop, it seems like the different commands I'm sending are not executed in order, or at least they are all executed at once, rather than waiting for one to finish before going on to the next. Was this handled differently pre-Lollipop? I am using the v1.60 Oct 10 release of libsuperuser.

Thanks for your awesome work.
16th November 2014, 09:13 AM |#48  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,733
 
Donate to Me
More
Quote:
Originally Posted by Flyview

Hi Chainfire!

I've been using your libsuperuser in my app to run some root commands. For example:



where rootCommand() is :



However, starting on Android Lollipop, it seems like the different commands I'm sending are not executed in order, or at least they are all executed at once, rather than waiting for one to finish before going on to the next. Was this handled differently pre-Lollipop? I am using the v1.60 Oct 10 release of libsuperuser.

Thanks for your awesome work.

They are executing in order, you're just not executing them in the right context, probably, so SELinux denies these commands. There's a whole section in my document about context switching, check that. You probably want the settings commands to execute as system_app.
16th November 2014, 10:41 AM |#49  
Senior Member
Thanks Meter: 58
 
More
I am running into a sugote issue, like the person with the backup app on the long thread. This happens in my own app, so I can easily reproduce it.
It happens when I call process.waitFor(). The call is followed in logcat with:

Code:
F/libc    (17322): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb4da21f0 in tid 17366 (Binder_1)
E/DEBUG   (  186): unexpected waitpid response: n=17366, status=00000000
E/        (  186): ptrace detach from 17366 failed: No such process
E/        (  186): debuggerd committing suicide to free the zombie!
The waitFor() won't return and I see a new sugote process eating CPU.
Here the code context (simplified):
Code:
Process proc = exec(new String[]{"su","--context","u:r:system_server:s0"});
DataOutputStream os = new DataOutputStream(proc.getOutputStream());
os.writeBytes("stop adbd\n");
os.flush(); 
os.close();
proc.waitFor();
Interestingly the "stop adbd" command actually works. (It does seem to require system_server.). And when I omit the call to waitFor(), things appear fine. Except for the cpu-eating sugote leftover. I'm using SuperSU 2.16 on Android 5 on a N7 2013.
16th November 2014, 11:11 AM |#50  
Chainfire's Avatar
OP Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 86,733
 
Donate to Me
More
Quote:
Originally Posted by t1mur

I am running into a sugote issue, like the person with the backup app on the long thread. This happens in my own app, so I can easily reproduce it.
It happens when I call process.waitFor(). The call is followed in logcat with:

Code:
F/libc    (17322): Fatal signal 11 (SIGSEGV), code 1, fault addr 0xb4da21f0 in tid 17366 (Binder_1)
E/DEBUG   (  186): unexpected waitpid response: n=17366, status=00000000
E/        (  186): ptrace detach from 17366 failed: No such process
E/        (  186): debuggerd committing suicide to free the zombie!
The waitFor() won't return and I see a new sugote process eating CPU.
Here the code context (simplified):
Code:
Process proc = exec(new String[]{"su","--context","u:r:system_server:s0"});
DataOutputStream os = new DataOutputStream(proc.getOutputStream());
os.writeBytes("stop adbd\n");
os.flush(); 
os.close();
proc.waitFor();
Interestingly the "stop adbd" command actually works. (It does seem to require system_server.). And when I omit the call to waitFor(), things appear fine. Except for the cpu-eating sugote leftover. I'm using SuperSU 2.16 on Android 5 on a N7 2013.

The CPU eating should be solved in the next update (I still have to test your example case, but TiBu causing it has been fixed).

What are you basing the above code on, though? Because waitFor() should indeed never return. What you're doing is starting an interactive shell with the su command, then writing the command to stop adbd to it. Instead of closing the shell by issuing an exit command, instead you close the shell's STDIN.

Whether or not a process terminates on closing their STDIN is completely unreliable (though many processes do) and a bad practise in general. Unfortunately, this is a common case among root apps.

If only devs would use one of the several tried and tested libraries instead of insisting on rolling their own methods that invariably fail somewhere.
16th November 2014, 11:43 AM |#51  
Senior Member
Thanks Meter: 58
 
More
Quote:
Originally Posted by Chainfire

Whether or not a process terminates on closing their STDIN is completely unreliable (though many processes do) and a bad practise in general. Unfortunately, this is a common case among root apps.

Ah yes, this just work when I exit the shell. For some reason I so far never ran into this. Thank you.
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes