yashsingh1/xdaforums huggingface dataset:
[SuperSU] 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.
[SuperSU] Chainfire:
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.
[SuperSU] 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:

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):

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.
[SuperSU] Chainfire:
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.
[SuperSU] t1mur:
Ah yes, this just work when I exit the shell. For some reason I so far never ran into this. Thank you.
[SuperSU] Flyview:
Thanks for the response. I will look into switching context. To get around selinux I had also been calling setenforce 0 and setenforce 1 right before and right after those commands. This is probably terrible practice?

The su commands are definitely getting called successfully, but not reliably, until I separate them with delays. This is why I thought maybe the commands were running out of order, or concurrently.

Sent from my Nexus 5
[SuperSU] Chainfire:
The very worst.
[SuperSU] Flyview:
Understood. I've also seen something strange happen where after running my superuser code, once in a while, the whole system starts crashing. Apps just close, and eventually it gets very slow, logcat can't even keep up with the errors. Then after powering down and back up, apps are "updated" again (re-odexed?). I wonder, is it the same phenomenon that you mention on your site?
[SuperSU] Flyview:
I just wanted to update that everything has been working as planned after adding in a su command to switch context to system_app. Thanks Chainfire!
[SuperSU] Flyview:
Hi Chainfire,

Please help me with one other thing. I have noticed on Lollipop that after running root commands from my service, the service continues to grow in size at almost 1mB after every call. This was not happening on KitKat. The only thing that has changed is the addition of the context switching command. Am I doing something wrong?

I got this from Eclipse's Memory Analysis Tool (MAT):
[SuperSU] Flyview:
I've tried to debug what's going on in the Shell.SU.run method. Please see the System.out.println lines I've added. Only the first 1 (TEST1) is reached! It looks to me like proc.waitFor takes forever and the "gobbling" keeps going. This line *is* reached, however, if I do not switch the context to system_app in my root commands that I send.

This is on Android Lollipop, SuperSU 2.27, and the latest libsuperuser.

EDIT: I think I fixed it by running my root commands without "su" before --context u:r:system_app:s0

rootCommand(new String[]{

"--context u:r:system_app:s0",

"settings put secure location_mode " + (enabled ? originalLocationMode : newSetting),

"settings put secure location_providers_allowed " + (enabled ? originalLocationProviders : newLocationProviders)});

}
[SuperSU] Chainfire:
Shell.run("su --context u:r:system_app:s0", new String[] {
"settings put secure location_mode " + (enabled ? originalLocationMode : newSetting),
"settings put secure location_providers_allowed " + (enabled ? originalLocationProviders : newLocationProviders)
}, null, true);
[SuperSU] Chainfire:
Lots of 5.0 info added the document.
[SuperSU] Archipelt:
I was wondering if the restriction of running binaries outside of the /system partition is lifted by SuperSU? Users report no problems and in my testing all seems well, but can I depend on this to work in the future?

Thanks a lot for your work Chainfire.
[SuperSU] Chainfire:
Yes it is. And I will do my very best to keep that so.
[SuperSU] mikereidis:
I have been running binaries on Lollipop and Kitkat outside of /system without root, using the app lib directory.

Eg: /data/data/appname/lib/libssd.so which can map to /data/app/appname-1/lib/arm/libssd.so

These are PIE executables written in C, built with NDK and named *.so to pretend to be a shared library.

Google may (will ?) break this in future, but so far it works on every device & ROM I have tried. IE 10 different popular devices from the last several years running Kitkat or Lollipop ROMs, including the GPEs for One M7 and M8.

SELinux enforcing or not does not matter.
[SuperSU] Chainfire:
There was never an issue with this - and I doubt there will be... The restriction root ran into before we patched the policies existed to prevent /system apps to be exploited to run scripts and executable on /data, which should never happen on stock Android. As long as you run under normal app permissions, there's no need to restrict it.
[SuperSU] Archipelt:
Is there a way to make SuperSu check for a new su binary? Perhaps by broadcasting? I know that it checks on boot (not going that broadcast that), but it would be nice to initiate a check since I notice many users don't update.

Thanks
[SuperSU] idler1984:
su.d failed on Sony Xperia Z3 (D6633)

I'm using SuperSU 2.40 and seems /system/su.d failed to work on Sony Xperia Z3 (D6633)

Basically it consists of a script in /system/su.d (krspatch.sh) and a kmem patch utility in /system/xbin (kmempatch). The script loads the patch utility and keeps it running in background. It is used to in-memory-patch system partition protections like sony_ric or similar stuff in some other brands.

/system/su.d/krspatch.sh:

#!/system/bin/sh
x=`/system/bin/cat /proc/version`
y="Linux version 3.4.0-perf-g3a93840 (BuildUser@BuildHost) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Thu Aug 21 17:06:54 2014"
if [ "$x" == "$y" ]; then
/system/xbin/kmempatch 3238908896 1 0 &
fi

I've also added debug output in kmempatch. It seems the script didn't run or failed to bring up the binary, since the entry log at the very beginning of kmempatch failed to print. However, identical script and binary works on Huawei Ascend Mate 7 and Honor 6 Plus.

It is possible to debug the process of su.d folder?

Thanks.
[SuperSU] Chainfire:
Two things may be relevant:

(1) su.d execution had some bugs in v2.40 you may be encountering, please check with the latest beta (currently v2.43)

(2) depending on exact SELinux policies on your device, /system/bin/sh may modify context that may be preventing your script from working, try using /tmp-mksh/tmp-mksh or /system/xbin/sugote-mksh instead

If neither of these two fixes the problem, we can investigate further.
[SuperSU] idler1984:
Thanks.

I've switched to 2.43 and run following tests.

1. Regarding SELinux, I appended line "setenforce 0" to /etc/install-recovery.sh. Upon boot I can see SELinux is in permissive mode, but the script was still not running.

2. Then I tried appending line "/system/xbin/kmempatch 3238908896 1 0 &" to /etc/install-recovery.sh directly, and kmempatch was successfully loaded upon boot.

To clarify, this is how the install-recovery.sh looks like:

#!/system/bin/sh

# If you're implementing this in a custom kernel/firmware,
# I suggest you use a different script name, and add a service
# to launch it from init.rc

# Launches SuperSU in daemon mode only on Android 4.3+.
# Nothing will happen on 4.2.x or older, unless SELinux+Enforcing.
# If you want to force loading the daemon, use "--daemon" instead

/system/xbin/daemonsu --auto-daemon &

# Some apps like to run stuff from this script as well, that will
# obviously break root - in your code, just search this file
# for "install-recovery-2.sh", and if present, write there instead.

/system/etc/install-recovery-2.sh
setenforce 0
/system/xbin/kmempatch 3238908896 1 0 &

Regarding /tmp-mksh/tmp-mksh, it seems missing on the still-locked device due to the lock. Currently I haven't figured out a way to create it while retaining the lock. Could this be the reason?

Anyway I suspect install-recovery-2.sh can be a workaround for now :) (tested)
[SuperSU] Frank Westlake:
Create '/system/etc/install-recovery-2.sh' and move your additions to that file. The file ' /system/etc/install-recovery.sh' might be replaced by the 'su' installation and you would lose your customization, but they will be preserved and called if they are in 'install-recovery-2.sh' .

Frank
[SuperSU] Chainfire:
Not sure what could be going on here, but tmp-mksh being missing does not bode well. It should be present on all daemon-based su installs.
[SuperSU] OOPMan:
Hi Chainfire

Thanks for the work you've done on this.

I've just started work on a Scaloid project that I intend to make use of su in.

I see that libsuperuser is can be included via a Gradle dependency, however Scaloid projects use SBT.

Is the code in libsuperuser mostly presented just as an example or should I find a way to make use of it?

If so, how should I include it? Should I compile to to produce a jar that I can add to my project as a dependency?
[SuperSU] Chainfire:
I know nothing about scaloid or how this would work with it.
[SuperSU] OOPMan:
No worries, I worked out how to include libsuperuser :)
[SuperSU] JFDee:
SU call immediately after boot

Deleted, wrong thread, new one added.
[SuperSU] mcnamaragio:
I have an app which uses service command to issue a command like this:

service call notification 1

It works on most of Android 5.0 devices correctly but on Samsung devices (mainly S5 and probably on S6 too) it fails with message "service notification does not exist".

When I asked users to issue "service list" command from terminal emulator it returned "Found 0 services" instead of listing services. This was happening with SuperSU version newer than 2.23 (2.40 in one case) Other apps such as Titanium backup, root explorer, busybox all work without issues.

Is there anything I need to do to make sure it works correctly on Galaxy S5 ?
[SuperSU] Chainfire:
This might help, run from a su shell:

supolicy --live "allow servicemanager init dir search" "allow servicemanager init file { open read getattr }" "allow servicemanager init process { getattr }"

(the above is a single line)

If this solves it, the issue will go away for your users from SuperSU v2.49 where this is integrated. Very recent Samsung firmwares have some new policies that mess with the 'service' stuff.
[SuperSU] mcnamaragio:
Running the command helped. Thanks.

Can I add that command to my app before running other commands? Will it cause any compatibility issues with SuperSU after 2.49 is released? Is there any release date planned?
[SuperSU] Chainfire:
You can, but it is better to recommend the new SuperSU version to users seeing this issue. It should be released this week. This is better because changing policies can cause crashes (rare, but it happens) so if its not absolutely necessary don't do it. SuperSU will be handling this very soon, so there is no real need for you to do it yourself.
[SuperSU] mcnamaragio:
Was it released? I don't see an update.
[SuperSU] mcnamaragio:
I have one user who has 2.48 installed but service list still returned zero services. Running the command you advised did solve the issue.
[SuperSU] Chainfire:
2.48 is from before that post. 2.49 isn't out yet.
[SuperSU] mcnamaragio:
OK, Sorry I mixed the version. Any estimated date for 2.49 ?
[SuperSU] Psych0Chimp:
A few users are reporting trouble with my app being able to write to a directory at the root of the "sd card" - I get a "no such file or directory" error when I'm trying to save a file from an SU shell.

To get the path of the sd card, I use a bit of code borrowed from the Android Environment class.

When the path is of the form '/storage/emulated/0' (as on my Nexus 5 running Kit Kat), it works fine.

However, if the path to the root returned by the Android Environment class is of the form '/storage/sdcard0' then it fails with the above error.

Turning off the "Mount namespace separation " setting in SuperSU seems to fix it, but I was wondering if there is a better way to work around the issue?

Ideally without having to instruct the user to go into SuperSU and change the setting...

Maybe something to do with the shellMountMaster() method? How can I use this with an Interactive SU shell created using the Builder?

Any ideas welcome!
[SuperSU] ballzak:
is the system running?

On some devices running the "am" command in a su shell will fail with:

Can't connect to activity manager; is the system running?

Does someone have any idea what's causing this?

This may not be a SuperSU specific issue, but it's certainly also affected.
[SuperSU] Chainfire:
libsuperuser has been updated with the Toolbox and Policy classes. See GitHub.
[SuperSU] mcnamaragio:
Some users who use kingo root complain that my app is unable to detect su. I just call Shell.SU.available() to detect root. Is there any workaround for this bug?
[SuperSU] Chainfire:
Reproduce it, find the error, fix the error, submit a pull request.
[SuperSU] rovo89:
Is there any chance to change an mlsconstrain and/or create a new domain using supolicy? In Marshmallow, apps run with context levels depending on the user, and their preferences are labelled accordingly. I tried to switch a new process to something like "u:r:untrusted_app:s0:c0.c1023", but unfortunately, the policy allows access only when the levels match exactly:

# Subject must be equivalent to object unless the subject is trusted.
mlsconstrain dir { open search setattr rename add_name remove_name reparent rmdir }
(t2 != app_data_file or l1 eq l2 or t1 == mlstrustedsubject);
mlsconstrain { file lnk_file sock_file } { open setattr unlink link rename }
(t2 != app_data_file or l1 eq l2 or t1 == mlstrustedsubject);

I could easily make untrusted_app an mlstrustedsubject, but that would probably be insecure. If I could create a new domain instead, I could make it trusted. Or even better: If I could rewrite that constrain to be similar to others ("l1 dom l2" instead of "l1 eq l2"), I think the wildcard context should work.
[SuperSU] mikereidis:
So does system_app context not work on some MM 6.x ROMs now ?

su --context u:r:system_app:s0

I had it working from command line, but from my app it results in an SELinux denial on my HTC One M8 with stock Android 6 and systemless SuperSU:

12-15 01:48:28.510 I/daemonsu(13884): type=1400 audit(0.0:266): avc: denied { setcurrent } for scontext=u:r:init:s0 tcontext=u:r:init:s0 tclass=process permissive=1

1

Android seems to be getting locked up tighter with each new major release. I'm starting to wonder if it's still worth the trouble to do root apps, at least on stock devices/ROMs....
[SuperSU] Chainfire:
Sorry I completely missed this post. Did you solve this, and if so, how?

You cannot create a new domain using supolicy at this time. I've tried doing this at some point but failed.

Regarding mlsconstrain, I think I remember messing with mlstrustedsubject and didn't get the desired effect either.

The "permissive=1" part shows its just a warning being logged, it's not actually denied. I'm not saying its working, just that this line isn't the problem.

Check the output of id when ran as system_app from your app and see what it says.
[SuperSU] mikereidis:
Thanks ! You are correct, and my problems were elsewhere.

SuperSU-v2.62-3-20151211162651 is working well for me, and I think it avoids the random no SU on some reboots issue I had with v2.61.
[SuperSU] rovo89:
No, I didn't find a solution yet, I was too busy with other issues. For Xposed, I might use a native service running in the correct context (untrusted_app + level for the owner/primary user). That's what I already do for the system_server process, which can't access app data files either. However, I obviously don't want to give any app the possibility to use the native service to ready any file, so I need to come up with a way to limit it to modules, which will need many careful thoughts. Currently, it rejects calls from UID != 1000 (system_server).
[SuperSU] Flyview:
Hey [MENTION=631273]Chainfire[/MENTION] ,

Posting here as you suggested. I use SuperSU in my LeanDroid app. When Lollipop came out you showed me how to switch SELinux contexts before running the root command that at the time wasn't working, since it accesses a system method. Fast forward to Android 6.0.1 and out of curiosity, I tried running the root command through the app without switching contexts (SELinux enforcing). Surprisingly, it still worked. I have SuperSU 2.67 installed on my device. Has something changed in SuperSU or Android that no longer requires switching contexts?

Thanks!
[SuperSU] Chainfire:
Newer SuperSU versions have solved most (but not all) of the occasions where you needed to do this. It's certainly possible in your case the switch is no longer necessary.
[SuperSU] nikanuka:
add/embed supersu.zip in custom *.img firmware

good day

trying to add/embed supersu.zip in custom *.img Lollipop firmware

boot supports *.sh scripts, so in bin directory i have one with name installApk.sh with contents

#!/system/bin/sh

APP_MARK=/data/local/symbol_data_app

app_success_flag=0

cd data/app

if [ ! -e $APP_MARK ]; then

until [ $app_success_flag -eq 1 ]

do

busybox unzip /system/usr/apks.zip -o -q -d /data/app/

if [ $? -eq 0 ]; then

for file in $(ls *.apk)

do

#busybox cp -f /system/usr/$file /data/app/

echo "chown system:system /data/app/$file"

echo "chmod 644 /data/app/$file"

chown system:system /data/app/$file

chmod 644 /data/app/$file

done

app_success_flag=1

touch $APP_MARK

else

app_success_flag=0

fi

echo "data app sleep 1"

sleep 1

done

fi

so if i place supersu.zip in the directory /system/usr/ what command should i add in above *.sh script?

this one do not work

unzip /system/usr/supersu.zip META-INF/com/google/android/* -d /tmp

sh /tmp/META-INF/com/google/android/update-binary dummy 1 /system/usr/supersu.zip
[SuperSU] Chainfire:
The ZIP file does require a recovery-esque environment. The script would probably need massive adjustments to be able to work from Android boot. I think really the only way is doing this manually.
[SuperSU] nikanuka:
Thanks for the answer

to be honest all I'm trying to do is to be not prompted about binary updates at first run.

had placed all required binaries in corresponding directories but it still needs update after first run...

Successful result gained on kitkat 4.4.4 firmware as i had placed files in corresponding folders - no prompt for binary updates.

app/Superuser.apk

bin/.ext/.su

lib/libsupol.so

xbin/daemonsu

xbin/su

xbin/sugote

xbin/sugote-mksh

xbin/supolicy
[SuperSU] Chainfire:
That's great. Read the script inside the ZIP and figure out which files you are missing where.
[SuperSU] nikanuka:
So as i mentioned before - this procedure goes smoothely on kitkat 4.4.4 with these files in corresponding directories

app/Superuser.apk

bin/.ext/.su

lib/libsupol.so

xbin/daemonsu

xbin/su

xbin/sugote

xbin/sugote-mksh

xbin/supolicy

never prompted abou binary updates (SuperSU 2.66)

but its does not works on Android Lollipop 5.1

what i see in /asserts/99-supersu.sh inside apk is

app/Superuser.apk

app/SuperSU/SuperSU.apk

xbin/su

xbin/sugote

xbin/sugote-mksh

xbin/daemonsu

xbin/supolicy

xbin/otasurvival.sh

lib/libsupol.so

lib64/libsupol.so

bin/log

bin/.ext/.su

etc/init.d/99SuperSUDaemon

etc/install-recovery.sh

etc/.installed_su_daemon

had placed all in corresponding directories but without success - still prompts about updates at first run.
[SuperSU] Chainfire:
As I said, read the script. Which would be the META-INF/.../.../..../update-binary file. If you can't figure it out with the information in there, you're not going to figure it out.
[SuperSU] Chainfire:
Any audit logs from dmesg, logcat, or /data/misc/audit ?
[SuperSU] AnkitChowdhury:
Yes. Please check the post again. I've added the audit logs recently.
[SuperSU] Chainfire:
Try "attradd { uhid_device input_device } { mlstrustedsubject mlstrustedobject }". Not quite sure about this one.
[SuperSU] Chainfire:
Note of course that a better solution would be running whatever handles this input as root, and have it communicate with your main app over sockets and pipes, rather than adjusting security settings for all appdomain/untrusted_app.
[SuperSU] AnkitChowdhury:
Sorry for taking long to test. While the policies are patched successfully. It unfortunately doesn't make a difference. As the uinput module still remains inaccessible.

I actually tried it with another device on Lollipop just to make sure there isn't any problem with my code. On Lollipop the Virtual Touch Screen creation was successful and everything worked the way it should've. Thanks for trying to help. Is there anything else we can do? The lack of audit messages aren't helping either.

---------- Post added at 04:52 AM ---------- Previous post was at 04:48 AM ----------

Yes I understand that. It was a bad design decision. Choosing to use JNI libraries.

It'll be great if you could provide any solution to my current issue. If nothing works out unfortunately I will probably have to rewrite most parts of the app. Thanks again though. :)

---------- Post added at 05:01 AM ---------- Previous post was at 04:52 AM ----------

I also noticed something new in the audit logs in Marshmallow. Something like this " untrusted_app:s0:c512,c768 " . Does this signify anything new?
[SuperSU] AnkitChowdhury:
Hello [MENTION=631273]Chainfire[/MENTION], I've tried to do a bit of research regarding my issue. The problem as it seems is that I'm using JNI Library instead of JNI Executable.

Had I used JNI Executable I could have spawned it through my app from SU shell and could've changed it's context. But I'm using JNI Library and use an interface to call C/C++ functions via Java.

This way the library is loaded by the app and uses the app's context. Which is untrusted:s0. Even with Root access my Application's context doesn't change to init:s0. Only the supersu shell has init:s0 context.

Is there anyway we could change the context of my App to init:s0 or maybe system_app:s0? This might solve my issue I believe. I would really appreciate if you could help me with this, the one last time.

Thanks again. :)
[SuperSU] Chainfire:
Yes, it's called MLS/MCS. This is why I asked you try mlstrustedobject / mlstrustedsubject. It's a tricky subject and annoying to work with.

http://selinuxproject.org/page/NB_MLS

Unfortunately that is not currently possible.
[SuperSU] AnkitChowdhury:
Nevermind. Thanks a lot for your time. :)