yashsingh1/xdaforums huggingface dataset:
[SuperSU] Surge1223:
[MENTION=631273]Chainfire[/MENTION] are you using sush to change the default path? After boot even though init.environ.rc is patched? The reason I ask is because when I switch to root user in shell and thus the shell changes from mksh to sush, my path changes and for some reason sbin isn't in either path (not as su or default shell user)

I noticed sush evaluates the default path but I don't know if this is intentional or if it's related to something I've messed up on my part

The only differences from the patched ramdisk that supersu 2.66/67 creates and my current ramdisk is that I changed the perms for /su to 750 instead of 755 and I added some paths to init.environ.rc

# set up the global environment
on init
export PATH /su/bin:/sbin:/vendor/bin:/system/sbin:/system/bin:/su/xbin:/system/xbin:/sbin:/data/local/tmp:/data/toolchain/bin:/tmp/bin
setenv LD_LIBRARY_PATH /data/vendor/lib64:/vendor/lib64:/data/lib64:/system/lib64:/data/vendor/lib:/vendor/lib:/data/lib:/system/lib:/data/toolchain/lib
export ANDROID_BOOTLOGO 1
export ANDROID_ROOT /system
export ANDROID_ASSETS /system/app
export ANDROID_DATA /data
export ANDROID_STORAGE /storage
export EXTERNAL_STORAGE /sdcard
export ASEC_MOUNTPOINT /mnt/asec
export BOOTCLASSPATH /system/framework/core-libart.jar:/system/framework/conscrypt.jar:/system/framework/okhttp.jar:/system/framework/core-junit.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/telephony-common.jar:/system/framework/voip-common.jar:/system/framework/ims-common.jar:/system/framework/apache-xml.jar:/system/framework/org.apache.http.legacy.boot.jar
export SYSTEMSERVERCLASSPATH /system/framework/services.jar:/system/framework/ethernet-service.jar:/system/framework/wifi-service.jar
[SuperSU] Chainfire:
sush is just a copy of /system/bin/sh with a different SELinux context applied. Nothing more, nothing less.

I don't know either. /sbin is in my $PATH on my test device both with and without root.

Why would you change it to 750 ?

Not sure if your env changes can cause this, tbh.
[SuperSU] Chainfire:
This only happens when SuperSU is embedded in another ZIP ?

It does smell of a memory issue, but indeed the output is weird.
[SuperSU] nkk71:
Yes, only when embedded in another ZIP.

I tried the exact same ROM without SuperSU installation chained in the installer; then immediately flashed SuperSU 2.67 afterwards, and it went through perfectly.

Also using the copy to a tmp file "wrk_boot.img", also worked fine directly in the embedded zip.

What I find most peculiar is the output of the --backup , which was done on a clean reboot into recovery, so plenty of free space

- backing up from file, yields proper size and sha1

- backing up from "fake" mmcblk, yields incorrect size and wrong sha1

---- but running sha1sum on the fake mmcblk gives the correct sha1

---- and cp from fake mmcblk, as well as dd from fake mmcblk, also work properly

As for the memory issue, I'm honestly uncertain, the device in question is the HTC One M8 (tested on GSM and Sprint variants), which reports 1.8GB space in recovery, 1.6GB free.

The ROM itself is ~500MB compressed and ~1GB uncompressed, that should still leave enough "working space" for pretty much anything
[SuperSU] Flyview:
Hey [MENTION=631273]Chainfire[/MENTION] , I've been using the context switching command to make the root commands work in my app LeanDroid. You probably don't remember but when Lollipop was new you showed me how to use your SuperSU library to switch context to system. As I understood this was in order to get around selinux restricting my root commands which involve system processes. My app calls the "phone" service through root and it seems that they only work by switching the context to system. I have been requiring my users to have SuperSU as their root, as for example CyanogenMod's built in root still isn't working. Is SuperSU still the only root option that allows context switching or can I code the call to work with other root modules as well?

Thanks for your time!

if(systemAppContext) {
Shell.run("su --context u:r:system_app:s0", commands, null, false);
} else {
Shell.SU.run(commands);
}
[SuperSU] Chainfire:
Have you had any more discoveries about this by any chance?

This should probably have gone into the 'How-To SU' thread.

I don't really know which other root tools can and can't do this. You'll have to do that investigation yourself.

Why would you even do this instead of normal SuperSU installation? I don't know why exactly it doesn't work, but you're asking for issues.
[SuperSU] dr.ketan:
I have seen two roms today in N5 developer section and seems rom having stock kernel and system less root so embedded in other zip should work. Though I have not look script but just for acknowledge if [MENTION=2605798]nkk71[/MENTION] want to explore.
[SuperSU] Chainfire:
This is some excellent bug hunting!

Please confirm the attached version fixes the issue.
[SuperSU] nkk71:
Perfectissimo :good::good:

adb shell confirms no more truncation

embedding the above SuperSU without any other changes into the previously problematic ROM, now works perfectly

recovery.log also confirms no issues at all during installation

Many thanks :D

Oh, and yes, the ROM booted fine (auto-reboot on first bootup, second boot went fine), and SuperSU working perfectly.
[SuperSU] garyd9:
Chainfire, is there any chance that "custom_boot_image_patch.sh" can be called BEFORE the boot image (and ramdisk) is repacked?

Or better yet, perhaps a new optional script allowed for that would be run while the ramdisk is still opened up? ("custom_ramdisk_patch.sh")

It would be useful for changes to default.prop or init*rc files on systemless root...

Thanks

Gary
[SuperSU] Chainfire:
I'll consider it.
[SuperSU] :
Hey Chainfire, a few questions here:

-The sepolicy commit is still required to boot in enforcing, correct?

-As of 2.67, it's still required to re-bump after flashing on LG devices, correct? If so, wouldn't a simple solution be to just add an additional zip to the main OP which re-bumps it?

I had a few more as well, just can't remember them off the top of my head :-/
[SuperSU] Chainfire:
That commit is only required if you want a system-based su installation. It's not needed for system-less root. It's still in testing, though.

Bumping is still required for the G3. Not sure about any other LGs. However, SuperSU does allow for a post-boot-image-patch script to be executed, I'm surprised nobody has made a ZIP yet that simply installs this script and makes all future flashes auto-bump the image.
[SuperSU] Khaon:
[MENTION=631273]Chainfire[/MENTION]

sorry if you already answered this, but I don't think you did.

Currently I am using your su binary.

however, i have to use 2.56 because upwards version fails.

Why? I guess it is because i am using android master branch.

This is what I added

My question is : currently is it worth trying to get latest working ?

Do I need some more change to make 2.67++ works ?

Thx you.
[SuperSU] :
Sounds like something that could be easily worked into TWRP, thanks!
[SuperSU] dillenshards:
How to find
[SuperSU] k1ks:
Hi [MENTION=631273]Chainfire[/MENTION].

I glimpse me SuperSu.zip do not kill KingRoot in recovery in the case of a root with.

I think it would be much appreciated if the zip had this power.

I can give you the path.
[SuperSU] Chainfire:
What are you doing? Making a custom ROM? Or just a custom boot image? Is there any reason you are not just embedding the SuperSU ZIP itself, as documented at http://su.chainfire.eu/ ?

Feel free to post those paths :)
[SuperSU] k1ks:
This should eliminate the odd root :

am kill com.kingroot.RushRoot

pm uninstall com.kingroot.RushRoot

am kill com.kingroot.kinguser

pm uninstall com.kingroot.kinguser

rm /system/app/Kinguser.apk >/dev/null

rm -r /system/app/Kinguser >/dev/null

am kill com.kingroot.master

pm uninstall com.kingroot.master >/dev/null

busybox chattr -ia /system/xbin/ku.sud

rm /system/xbin/ku.sud

busybox chattr -ia /system/xbin/kugote >/dev/null 2>&1

rm /system/xbin/kugote >/dev/null 2>&1

busybox chattr -ia /system/xbin/su

rm /system/xbin/su

busybox chattr -ia /system/xbin/supolicy

rm /system/xbin/supolicy

busybox chattr -ia /system/xbin/pidof >/dev/null 2>&1

rm /system/xbin/pidof >/dev/null 2>&1

rm -r /data/app/com.kingroot.RushRoot-1 >/dev/null 2>&1

rm -r /data/data/com.kingroot.RushRoot

rm -r /data/data-lib/com.kingroot.RushRoot

rm -r /data/app/com.kingroot.kinguser-1 >/dev/null 2>&1

rm -r /data/data/com.kingroot.kinguser

rm -r /data/data-lib/com.kingroot.kinguser

rm -r /data/app/com.kingroot.master-1 >/dev/null 2>&1

rm -r /data/data/com.kingroot.master

rm -r /data/data-lib/king >/dev/null 2>&1

busybox chattr -ia /system/bin/.usr/.ku

rm /system/bin/.usr/.ku

busybox chattr -ia /system/bin/rt.sh

rm /system/bin/rt.sh

busybox chattr -ia /system/bin/su

rm /system/bin/su

busybox chattr -ia /system/bin/ddexe-ku.bak >/dev/null 2>&1

rm /system/bin/ddexe-ku.bak >/dev/null 2>&1

busybox chattr -ia /system/bin/ddexe

rm /system/bin/ddexe

busybox chattr -ia /system/bin/ddexe_real >/dev/null 2>&1

rm /system/bin/ddexe_real >/dev/null 2>&1

busybox chattr -ia /system/bin/install-recovery.sh

busybox chattr -ia /system/bin/install-recovery.sh-ku.bak

busybox chattr -ia /system/usr/iku/isu

rm -r /system/usr/iku

rm -r /dev/reportroot

rm -r /system/app/Kinguser

rm -r /data/data-lib/king

rm -r /sdcard/Kingroot

rm /sdcard/kr-stock-conf >/dev/null 2>&1
[SuperSU] Khaon:
I am building AOSP master branch from scratch.

Flashing Supersu v2.60 and onnward fails with vanilla boot image ( so the boot image that get built from the prebuilt kernel image + the original ramdisk).

The only way I got SuperSU working was to use 2.56 in combination with editing the ramdisk as you told in the MM post.
[SuperSU] ViRb3:
I copy a file from /persist/ to the internal storage of my app using SU "cpy" and then I "chmod" it to 600 (unnecessary, but I wanted to see if it helps). I get "Access denied" exception whenever I read that file. I can read any other file I create.

EDIT: The owner was root and not my app.

EDIT2: And even when I changed it, I can still not touch that file - delete, read, write all fail. Please help me, my head hurts now...
[SuperSU] Chainfire:
chcon ?
[SuperSU] ViRb3:
Yes, that solved my problem immediately! Thank you so much!

Just out of curiosity, is this a safer method to make sure it works across all devices (with or without SuperSU; all states of SELinux), or should I "cat" the file instead? Also, what do "c512, c768" mean in the end of "u:object_r:app_data_file:s0:c512,c768"? They were the ones that made it readable by my app.
[SuperSU] Chainfire:
If "cat"ing it works (check for bytes that are misinterpreted by Java if it's not pure ASCII 0-127 text!), that would be most compatible. sX and cX are parts of MLS and MCS respectively, Google: SELinux MLS MCS.
[SuperSU] bigsupersquid:
I really hate to bother you here, but I have a SuperSu related question.

Custom build of cm13, july 5 security patchlevel, includes sepolicy patch from the sticky in this forum.

SuperSU installs fine from Play (normal install,) seems to work. After the sepolicy patch. But.

My log (logcat -db all | grep "su_daemon", also dmesg ) is getting spammed with

07-11 18:08:24.889 0 0 I : c0 1 init: Starting service 'su_daemon'...
07-11 18:08:24.905 0 0 I : c0 1 init: Service 'su_daemon' (pid 3124) exited with status 0
07-11 18:08:24.905 0 0 I : c0 1 init: Service 'su_daemon' (pid 3124) killing any children in process group
0

Can't seem to google up a fix other than maybe using the new beta supersu?

Thought maybe you might have a fix to point me at so I can implement it in the build to correct the core issue, or perhaps an idea of how I can get a more useful log of why it's not starting up.

or maybe I'm totally overlooking something terribly obvious and you may chastise me for it.

Thanks for your time and great work.
[SuperSU] Chainfire:
su_daemon is CM's su I think, and thus unrelated to SuperSU
[SuperSU] bigsupersquid:
well, that would certainly explain why i can't search any reference to it with supersu.

appreciate the response (though it does expose more of my un-education)

knowing that i can hunt it down and hopefully deal with it myself.
[SuperSU] topjohnwu:
Hello [MENTION=631273]Chainfire[/MENTION], I'm the original author of systemless Xposed.

Recently I released a systemless Xposed based on your latest 2.76 version, which loads on post-fs-data if possible.

[UNOFFICIAL][v86.0][July 12] Systemless / System Universal Compatibility Xposed

Several users reported that Xposed won't work on secure boot enabled devices (require password to boot up). By viewing the boot logcat, it seems SuperSU is not able to load on post-fs-data is this specific situation (I assumed it because there are other processes running at the same time when su.d scripts are executing, however no logs from SuperSU has shown. Although you did log which mode SuperSU is running in "log_print", launch_daemonsu.sh only logs in very few situations like image merging, apk moving etc., which in most cases there will be no logs showing which mode SuperSU is running with in logcat)

By viewing your scripts and the result boot image, I see you used similar techniques I used in my previous systemless Xposed versions to load in post-fs-data. However in my previous systemless xposed versions, I can handle secure boot devices. A wild guess is that you placed init.supersu.rc in the last of the import lists in init.rc, but other factors might cause daemonsu to fall back to service too, I'm not sure.
[SuperSU] Chainfire:
I'll have a look at this. I was actually afraid this would happen, but I'm pretty sure I tested it. Guess I made a breaking change afterwards.

Regarding logging, the mode in which SuperSU was started can be gotten by 'getprop sukernel.daemonsu.launch'.
[SuperSU] topjohnwu:
It is nice to show status in logcat because users provides them. Using getprop is useful for debugging on self owned devices, but for debugging remote devices, it requires users to do another step for developers to know the remote device status.

Just some recommendations.
[SuperSU] Chainfire:
On by far most devices I have tested on here (several dozen), logging at this stage does *not* show up in logcat *at all*.

Perhaps I'll add a generic message, perhaps not.
[SuperSU] Captain_Throwback:
FYI, here's the output of [MENTION=631273]Chainfire[/MENTION]'s command, on my HTC 10 with password-set-on-boot where Xposed isn't working:

PS C:\Users\capta\AppData\Local\Android\sdk\platform-tools> adb shell getprop sukernel.daemonsu.launch
post-fs-data

On every other reboot, I also seem to be losing mobile network connectivity. I'm not sure if that's SuperSU-related though, since the 10 is very touchy when it comes to that.

EDIT: Facebook and Messenger are also force closing on me with Xposed installed. I have no idea what that's about (but I think that may be more Xposed-related than having anything to do with SuperSU).

EDIT 2: I am noticing that in some apps, the prompt for root is taking much longer to pop up than it has with previous versions of SuperSU. For example, Root Explorer and Xposed are timing out when trying to get root, and the prompt doesn't show up for a minute or more after it should (if at all). UPDATE: I just checked again, and it seems the root prompt shows up after I close out of either app.
[SuperSU] puneet724:
I am getting force closures on facebook
[SuperSU] topjohnwu:
Sorry for the slight OT here. I don't know any better way to contact you [MENTION=631273]Chainfire[/MENTION]

May I ask you how you overcome the issues of some recoveries not supporting signed zip unzipping (like CWM)?

By viewing your updater-script for SuperSU, I can't seem to find where you have done your magic.

Thank you very much!
[SuperSU] Chainfire:
Disclaimer: I know very little about Xposed and I do not use it.

I have installed your systemless xposed on my 5X.

The installer says the framework is not installed, however the logs page shows xposed is loaded. Additionally, cat /proc/pid/mounts shows that both 32 and 64 bit zygote processes have the mounts loaded, and ps shows xposed services running.

Your mounts are loaded on my device in all these tests:

- unencrypted /data

- 'default' encrypted /data

- PIN encrypted /data

- password encrypted /data (two-stage system load)
[SuperSU] topjohnwu:
Have you used my XposedInstaller apk in my release thread OP? It is required.

The mount will work definitely, the problem is whether app_process mounts early enough. This is why bind mounting during post-fs-data and block other processes while executing scripts are so critical. One way to see whether Xposed has loaded correctly is by viewing logcat at boot. Apart from mounting logs(those are logged by my scripts), Xposed will also log its version number, XposedBridge path etc.

It seems that you also have a HTC 10. The user reported with issues is using secure boot (or verified boot I'm not sure about the name) on the 10. Maybe you may try it yourself and reproduce the issue.

BTW, would you also answer my question for unzipping signed zip? CWM have trouble flashing my Xposed zip.

Thank you very much!
[SuperSU] Chainfire:
Ah yes. Doh. "Xposed Framework version 86.1 (Systemless by topjohnwu) is active."

I don't have time to break my HTC10 right now.

I use my own tools for this.
[SuperSU] dark_boy99:
where are i can translate app for Persian user?
[SuperSU] Ingenium13:
This may be an odd request, but is there a way to have SuperSu pretend to grant an app a root shell, but not actually do it? Basically like a sandbox mode?

I have a situation where I'd like a log of the root shell commands that are trying to be executed, without actually allowing those commands to execute.
[SuperSU] side:
[MENTION=631273]Chainfire[/MENTION]

First of all thanks for our great work mister :)

question:

I am building a custom nougat rom on jf s4

latest supersu works fine on unlocked BLs but not on locked ones.

its error is

- Decompressing ramdisk
sukernel v2.78 (ndk:armeabi-v7a) - Copyright (C) 2014-2016 - Chainfire

Loading from [/sutmp/ramdisk.packed] ...

--- Failure, aborting
cp: can't stat '/sutmp/boot.img': No such file or directory

the workaround:

i booted a kernel with unlocked BL,so the kernel got patched.

i gave this patched kernel to the guy who uses locked BL and flashed it with loki

so he finally got a systemless root access with latest supersu package!

my question:

Can i somehow add su's required stuff inside the rom to have permament root? (that will skip ramdisk decompression)

Thanks in advance!

its in updater-binary
[SuperSU] dpj52190:
Chainfire I was reading up on how root access is gained in systemless root. I came across a thing called 'zygote64'. Could you explain how you are using zygote to gain root access. Also lately there's been zygote asking for root access. Are these 2 things related?
[SuperSU] Chainfire:
It depends on the Android version. On 5.x in system mode (not systemless!) the zygote executable (app_process, actually) is hijacked to start the su daemon. In systemless mode, nothing is done with zygote. If zygote is asking for root access, something else is going on - this is not SuperSU.
[SuperSU] Honestly Annoying:
Hello! I am attempting to install SuperSU through and adb root shell, as I am on a userdebug Sprint LG G5 (6.0.1) and am limited for now to this. I have tried every third party script I could find and none of them worked, so I attempted to run the QC Galaxy S7 installer instead. Everything runs smoothly except for the last step (second to last line from "launch_daemonsu.sh"), as I get this error.

root@h1:/ # /su/bin/supolicy --live
supolicy v2.74 (ndk:arm64-v8a) - Copyright (C) 2014-2016 - Chainfire

Patching policy ...
libsepol.policydb_read: policydb version 30 does not match my version range 15-29
- Failure! 2

Is there anything you can do to help with this?

Here is a link to my current thread: http://xdaforums.com/sprint-lg-g5/how-to/guide-adb-root-rw-dm-verity-off-sprint-t3523496
[SuperSU] Chainfire:
Replace su, daemonsu, supolicy, libsupol, and sukernel, with files from the 2.79-SR1 ZIP.
[SuperSU] Honestly Annoying:
I will try this and update you, thanks for the response!
[SuperSU] _alexndr:
[MENTION=631273]Chainfire[/MENTION]

I have a small but in my opinion very important proposal of change in your update-binary sh script

At this moment your SuperSU installer writes TWICE entire $BOOTIMAGE block. As you (probably) know - the most popular flash memory in currently available devices is TLC (Triple Level Cell) with about 1000-writes durability of single memory cell. This is not a big problem for /data as "system takes care" about not writing to the same cell until all available space has been physically used already.

This is also not a big problem for normal users which install your update once or twice a month

BUT IMHO this is real problem for Devs/Chefs who use your ZIP as a part of custom rom installer. Sometimes they perform 10 or more iterations before release ready for use custom rom. It usually means 10 times of custom ROM flash processes = 30 times of $BOOTIMAGE writes! (1 - pure stock kernel, 2 - wipe $BOOTIMAGE by SuperSU, 3 - kernel patched by SuperSU)

In case you accept below proposal your installer will write $BOOTIMAGE only ONCE and is still capable of cleaning unused part of $BOOTIMAGE:

[...]

[COLOR="Green"] if ($CONTINUE); then
if ($SAMSUNG); then
# Prevent "KERNEL IS NOT SEANDROID ENFORCING"
SAMSUNG_CHECK=$(cat /sutmp/boot.img | grep SEANDROIDENFORCE)
if [ $? -ne 0 ]; then
echo -n "SEANDROIDENFORCE" >> /sutmp/boot.img
fi
fi

DEV=$(echo `resolve_link $BOOTIMAGE` | grep /dev/block/)
if [ $? -eq 0 ]; then
ui_print "- Flashing boot image"[/COLOR]
[COLOR="Red"]cat /sutmp/boot.img /dev/zero | dd of=$BOOTIMAGE bs=4096 2>/dev/null[/COLOR]
[COLOR="Green"] else
ui_print "- Saving boot image"
dd if=/sutmp/boot.img of=$BOOTIMAGE bs=4096
fi
fi[/COLOR]

[...]

The most important change is marked in RED
[SuperSU] Honestly Annoying:
So after trying this, SuperSU is still stuck on asking me to update the binaries and fails whenever I try. If you wouldn't mind, can you check out the forum that I have going for this so we can get SuperSU installed on the G5? Here is a link.

Thanks so much for all of your work! :)
[SuperSU] zaclimon:
Hi everybody! I've been trying to get online kernel flashing directly using AnyKernel in the system itself. So far my testing has been pretty positive. (Doing every commands from an adb shell results in the kernel being correctly flashed) However, that's from a userdebug build without SuperSU installed. This is using a Nexus 4 on AOSP 7.1.1 with SuperSU v.2.79 stable.

Once SuperSU is installed (Systemless) and I attempt to flash the kernel, the repacked boot image doesn't seem valid anymore. Just in case, I tried with the stock kernel as well, the same result happened. At first I might think it is something related to init itself because I had the same kind of booting failure when porting Nougat. (On the Nexus 4, it stays on the Google logo for some time, then the logo fades a little bit and then the device reboots to recovery) The only thing that I could see that might make it fail is if the SELinux policies cannot be loaded for some reason after unpack/repack.

I was thinking that some permissions might have been altered which make init not being able to load the policies. it is possible that unpacking the image have broken some stuff that SuperSU needs in order for the device to boot correctly. Obviously, since I don't have UART cable, all of this is speculation... Though I wanted to know if anybody had this kind of issue while trying to patch with Systemless enabled. :confused:
[SuperSU] InterestingTwist:
[MENTION=631273]Chainfire[/MENTION]

I just built sepolicy from source with some changes, can that same sepolicy file by applied on most devices regardless of the Android version? Granted 5.0+. To get the sepolicy I built a ROM for the Nexus 6P then grabbed the sepolicy file from the out folder. It works great on my 6P but would it work on other devices as well?

Edit: I used supolicy to load it.