yashsingh1/xdaforums huggingface dataset:
[SuperSU] Chainfire:
From my quick look it appears as if the capabilities bounding set is the issue; all processes started from adb shell run without the much requires CAP_SYS_ADMIN, and thus mounting anything doesn't work (even though uid 0 and permissive SELinux). A way must be found to either escape the capabilities bounding set, or run commands as root from a different branch of the process tree. I didn't see any obvious way of doing this. On older devices, especially with ENG images, at boot time often a script from /data would be executed (easily hijacked) - this doesn't appear to be the case in this firmware though.
[SuperSU] Vinnom:
Hi!

I have a Huawei Nova. As I saw in G+ post that some code was included to provide superSU to Huawei devices I tried in mine. Yet, I had a failure as other times. I grabbed a recovery log and uploaded my boot image. Is there anything else you need to take a look regarding this matter? Thanks

Enviado de meu HUAWEI CAN usando Tapatalk
[SuperSU] tmittelstaedt:
Hi Chainfire,

Stock Droid Turbo XT1254 (Verizon)

Android 6.0.1 (installed after the OTA patches

kernel version 3.10.40-perf-g1577812

system version 24.91.5.quark_verizon.verizon.en.US

buildnumber MCG24.251-5-5

bootloader unlocked with Sunshine

twrp ver 2.8.7.0

system set to read-only in twrp

I tried installing SR1-SuperSU-v2.82-SR1-20170608224931.zip

twrp goes through the sequence, so far everything looks good,

issues the message: "system-less mode, boot image support required" which I expected

Goes to finding boot image

gets all the way to the bottom of that with no errors (it appears the boot image is patched) then

Creating ramdisk backup

--- Failure, aborting

Reboot the phone and no su.

Any suggestions or am I either stuck reverting back to Android 5.1 to get a stock image I can root, or going to unofficial lineage, old CM, etc.?
[SuperSU] GopalKaul:
Read only system won't work. Reflash TWRP
[SuperSU] Turkish007:
Hi mate, I am new to this and I have a question I want to root my Galaxy S7, install TWRP and SuperSU, do i need an SD Card for all this and why ?
[SuperSU] Surge1223:
#!/system/bin/sh

touch /data/local/tmp/test.sh

echo "mount -o rw,remount -t auto /system" >/data/local/tmp/test.sh

echo "touch /system/test" >>/data/local/tmp/test.sh

setcap "cap_sys_admin+ep" ./test.sh
getcap `pwd`/test.sh
chmod 777 /data/local/tmp/test.sh

. /data/local/tmp/test.sh

if [ -f "/system/test" ]; then
echo "test works!"
else
echo "test FAILED"
fi

I don't think this will work but it's worth a shot, I modify libcap to use a diff capability.h with a mix from androids private file system caps and others, I get this output from running the above in /data/local/tmp (I named it test)

granted im already properly rooted and have no issues mounting.. And you'd have to chmod as adb shell not through the script like I did but anyways, ya worth a shot.
[SuperSU] tmittelstaedt:
Droid Turbo

I already read thread https://xdaforums.com/moto-x-style/development/wip-systemless-root-t3263405

Systemless root does not need to modify the system partition so it should not matter if you click the checkbox in twrp to set the system read only. If, as you say, I should have set the checkbox in twrp to set the system read/write this is contraindicated by the entire point of a systemless root, don't you think? It would certainly be a good idea to insert a message telling the user to make sure the system was read/write that into the error message that Supersu spits out about the ramdisk!

This was the 2nd time that I had to revert the phone to Android 5.1 then forward to 6.0.1 after the "phone stuck on Motorola logo boot" so I got impatient and loaded LineageOS on it and now I have Android 7.1.2, and Supersu installed. (I left the system partition set to read/write when installing supersu from twrp)

As far as I can tell, everything is working, and I'm rapidly getting very spoiled by the lack of bloatware, so I may not get back around to testing with the Verizon rom again.
[SuperSU] Chainfire:
You need CAP_SETFCAP to be able to setcap, which they don't have.
[SuperSU] elliwigy:
couldnt we use getcap, sucap or execcap?
[SuperSU] rybshik:
system-less mode on LineageOS 14.1

When installing SuperSU on LineageOS 14.1, is it a good idea/beneficial to go "system-less mode" ?

Is it ok to force "system-less" by flashing superSUFixer.zip prior to flashing supersu.zip?
[SuperSU] elliwigy:
from what i was reading cant we use a process/binary that has setfcap/setpcap to "inherit" the cap within the thread?
[SuperSU] Jon8RFC:
If anyone is curious, I updated (flashed via TWRP, not fastboot) my Google Store Pixel XL from the July OTA to the August OTA (NJH47F) and flashed SuperSU successfully. My root apps and recovery still function properly.

The PixelFix version ( SuperSU-v2.82-SR1-20170615211546-PixelFix.zip ) of SuperSU is still good to go:

https://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133/post72686197#post72686197
[SuperSU] -Deco-:
It is (somewhat) beneficial, systemless means the /system partition is not modified which helps with SafetyNet checks.
[SuperSU] rybshik:
I thought it only applied to stock ROM (rooted, but otherwise not modified).

Does it make sense for a custom ROM as its /system partition modified anyway?
[SuperSU] -Deco-:
Yes - Android doesn't check if it's modified, it only checks if it is being modified. However, if you're wanting to pass SafetyNet I recommend using Magisk.
[SuperSU] rybshik:
I do not need Android Pay, and I am not overly concerned if my device is hacked or information is stolen as I do not store sensitive information on phones or on Google.

However, I do want my device be listed "Certified" in Google Play settings. Although not sure what's the benefit :)

So, I guess I need "system-less" SuperSU and, as I understand, flashing superSUFixer.zip will force it
[SuperSU] Chainfire:
SuperSU v2.82-SR2 released

SuperSU v2.82-SR2 has been released!

Release notes here: https://plus.google.com/+Chainfire/posts/YCoHDpNaY38
[SuperSU] Kisakuku:
Deleted.
[SuperSU] jcmm11:
Ok, so I want to try SBIN mode on a Nougat ROM.

Will the existing contents of /su get migrated to the new layout? I assume there's a /su/su.d equivalent. I have some user scripts in there. I also store some files, that are bind mounted, in the su partition. (Yes I realize scripts will need to be modified in any case)

I'm also guessing that apps like Adaway or busybox installers that install to /su/xbin will need to be modified.
[SuperSU] Chainfire:
No, nothing will be automatically migrated. You either start over or backup/restore the relevant files yourself. su.d still exists, but it is in /sbin/supersu/su.d (Android) or /data/adb/su/su.d (TWRP, never hardcode this path) now.

Similarly, if you added a directory to /su, you'd place that directory in /sbin/supersu now.

The /su path has been completely eliminated because it cannot be hidden from view from apps.

What to do with xbin is a good question. It doesn't exist anymore in SBIN mode. The reason for this is that /system/xbin has apparently been removed from O completely (I must admit I haven't checked all O devices for this yet, but it's gone on some, at least) so we cannot bind over that (/su/xbin_bind) and we are no longer manipulating the path, so the normal /su/xbin is currently lost as well. We might work around this by manually adding this path inside su shells, that wouldn't really interfere with non-root behavior. That is something to think about though, and first we need to gauge interest for it.
[SuperSU] jcmm11:
Thanks for the explanation. As far as xbin goes the question really becomes where do we put busybox? ROMs that pre-install it tend to use /system/xbin. Third party installers also use xbin (except Magisk?), either system or su. And since I suspect that most rooted devices have busybox I think interest will be rather high once the implications get known.

Just food for thought at the moment. I can't think of a definitive solution right now. Part of the question is do we want busybox available when not root. Based on what you said that may not be possible.
[SuperSU] Chainfire:
I haven't tried this, but one thing you might be able to do is this:

echo "BINDSYSTEMXBIN=true">>/data/.supersu

Then reflash SuperSU ZIP. After that, you can try installing busybox into /sbin/supersu/xbin_bind .

This might work (for now) but it certainly won't work on devices that do not have /system/xbin.

If you do end up trying this, let us know how it worked out.
[SuperSU] rybshik:
Thank you for a great product!

Could you make a flashable zip to execute

echo "BINDSBIN=true">/data/.supersu
[SuperSU] shoey63:
That's not how it works.

Enter the code in TWRP terminal, then flash the beta zip.
[SuperSU] rybshik:
Why not? There is 'superSUFixer.zip' which, when flashed, execute a terminal script to force system-less
[SuperSU] edzamber:
Like this by updater-script [emoji6]

ifelse(is_mounted("/data") == "/data", unmount("/data"));

assert(run_program("/sbin/mount", "-t", "auto", "/data"); || ui_print("data mounted"));
run_program("/sbin/sh", "-c", "echo '' >> /data/.supersu");

delete("/data/.supersu");

run_program("/sbin/sh", "-c", "echo 'BINDSBIN=true' >> /data/.supersu");

set_perm(0, 0, 0644, "/data/.supersu");

unmount("/data");
[SuperSU] vitjinka:
will there be a SuperSu v2.82 SR2 Hidden version?
[SuperSU] rybshik:
is it already included with SuperSU_v2.82_SR2 flashable zip?

If not, we need a separate flashable zip with this script
[SuperSU] osm0sis:
That's a bit much.. TWRP has a terminal under advanced options. Use it, the commands are very simple. Or just make the .supersu file beforehand and copy it around when you need it.
[SuperSU] rybshik:
Think of it as an accessibility feature :)

TWRP and terminal fonts and keyboard letters are small and easy to miss-type, especially in smaller-display phones
[SuperSU] osm0sis:
So do it on your desktop and copy the file around. adb push even. It's a simple text file you're creating.
[SuperSU] bemanet:
I have with SR2 the issue as the same in SR1 again , that my ext SD is not visible... After flash back to 2.82 I can see the ext.SD again...
[SuperSU] xell75:
[MENTION=631273]Chainfire[/MENTION] I'm just curious, how can it be that SuperSU can have a conflict with the extSDcard?
[SuperSU] Chainfire:
Can you be available for some live debugging through Hangouts or Skype or the likes?

I don't know, I cannot reproduce the issue on my end, and nobody who has the issue has answered my calls for in-depth testing so far. So all I can do is guess.
[SuperSU] bemanet:
[MENTION=631273]Chainfire[/MENTION]: I have a Galaxy Notepro 12.2lte and the following ROM with the latest build: https://xdaforums.com/galaxy-note-p...-cyanogenmod-14-0-android-7-0-nougat-t3476335

Which logs do you need ?

Thanks...
[SuperSU] Chainfire:
Do you know if the issue occurs on Samsung ROMs as well ?

I'd like the output of the 'mount' command from:

adb shell

adb shell + su

terminal emulator

terminal emulator + su
[SuperSU] bemanet:
I dont know about Samsung ROM. I have no samsung ROM two years ago....:laugh:

Can you please shortly explain, how I can create this logs ?

But I can do this only tommorrow.

Thanks
[SuperSU] Ibuprophen:
[MENTION=631273]Chainfire[/MENTION], please correct me if I'm wrong...

[MENTION=2197161]bemanet[/MENTION], i think what Chainfire meant was not only the Samsung Factory ROM but, Samsung ROM's in general (ie... LineageOS and such).

Chainfire had just provided (on his last post) the commands to enter within the TWRP's Command Prompt.

I hope i had clarified this :rolleyes: but, i really hope that i didn't botch this up... :o

______________

PLEASE NOTE: I welcome any member to help with further valuable information/clarification for any of my posts.
[SuperSU] jcmm11:
echo "BINDSYSTEMXBIN=true">>/data/.supersu

Ok, this appears to have worked to the extent that it seems that it bind mounted /system/xbin over /sbin/supersu/xbin_bind (had pre-installed busybox in /system/xbin which now also appears be in /sbin/supersu/xbin_bind

Adding a file in either directory causes it to appear in the other. Deleting removes from both.

But - this really doesn't buy us anything. /system/xbin is still in the PATH so we can just use that for the moment. And once O comes out we still won't have anyplace for busybox ?

And since /system/xbin is being mounted over /sbin/supersu/xbin_bind rather than the other way around we're not preventing /system from being updated (doesn't matter in my case, for others it will).

Note for people that want to try SBIN mode - su.img is deleted as part of the change so make a copy first in case you want to revert.

Now I need to try to setup a few things ?

Question - if we're modifying install scripts to use the new structure should we just use /data/adb/su? Or should I test for /sbin/supersu and use that if it exists?

Also just noticed that /sbin/supersu/xbin DOES exist (although not in the PATH). Anyway to use that directory for busybox?
[SuperSU] Alxoom33:
SR2 flashed without incident in my Pixel C running ODP4 and in my Nexus 6 Running Android 7.1.1 August patch, with the terminal commands supplied for N. I have not been able to install busybox in either device.
[SuperSU] Chainfire:
I'm sorry but if you do not understand what to do from my post, explaining it is going to take an hour. I'll try some testing with Lineage myself first.
[SuperSU] Chainfire:
Are you sure this is correct?

I just tried this myself and it mounts /sbin/supersu/xbin_bind over /system/xbin for me. It may appear the other way around because it copies the contents of /system/xbin to /sbin/supersu/xbin_bind first ? You can test it by adding a file to /system/xbin and seeing if it persists after reboot.

/system/xbin is still in the path yes, but if you were modifying /system anyway was there ever any real difference between using /system/xbin or /su/xbin? The point of /su/xbin was not needing to modify /system/xbin.

/sbin/supersu/xbin indeed is still created, but it isn't used. You could put busybox there, but indeed it will not be in the path. You could modify /system/etc/mkshrc to correct that until there is a better solution, though.

As for scripting, /sbin/supersu (preferred, bind mount) or /sbin/supersu_link (if absolutely needed, symlink) should be used. The /data/adb/su path may change at any time. Execution of files should always use /sbin/supersu, as this bypasses root detection on some devices.

Do you ever use busybox without root, btw?
[SuperSU] supermaus100:
Is the version also for the g8141?
[SuperSU] Ch3vr0n:
Make a backup, try it and find out. If you have problems, then report back WITH the problem.

Sent from my Nexus 6P with Tapatalk
[SuperSU] Daniel V.:
Hello guys,

I can not get root access on my MI5. I tried with the latest version (V2.82/SR1/SR2) and the previous version (V2.79), but without success. I receive an error - see attached screenshot.

Do you have any idea what's going on?
[SuperSU] Chainfire:
Magisk leftover?

Manually delete /data/custom_ramdisk_patch.sh
[SuperSU] Chainfire:
suhide-lite is here, for as long as it may last:

https://xdaforums.com/apps/supersu/suhide-lite-t3653855
[SuperSU] KaMyKaSii:
You said that new features would need SBIN mode, does that also include a new suhide? I remember that you had already said that you had two functional methods to hide root but that you would wait, probably to see how this battle with safetynet works and if it's worth the effort. So, do you still plan to work on something similar or do you really think it's a lost cause?

Ps: I left the Labs open for a new post for as long as it should. Now I've seen that you've actually posted something about it, but if you still want to respond, that's fine.
[SuperSU] Daniel V.:
I uninstalled Magisk before. How to access /data/custom_ramdisk_patch.sh if I don't have root access?
[SuperSU] Chainfire:
There is a file manager inside TWRP, and adb shell also has root in TWRP.
[SuperSU] jcmm11:
And this is what happens when you assume. When I saw the directory wasn't empty I assumed that /system/xbin was mounted on top.

For me there is no real difference. I have to modify system anyway in order to install A.R.I.S.E. For others that won't be true. I try to keep system mods to a minimum, most are done using bind mounts (font changes, a few config files) I'm also trying to think ahead.

The xbin overlay should work until a better solution comes along. And I very rarely use busybox without root. If root was required that wouldn't cause any real problems. If busybox wasn't available that would cause some problems ??

You misunderstood me on the scripting. I was referring specifically to update scripts within zip files for use with TWRP, flashfire, etc. At the present time neither /sbin/supersu or /sbin/supersu_link are available. I don't know if that will change in the future.

For the moment I have to use /data/adb/su. My question was really am attempt to see if it was possible to future proof this in any way. This is even more desirable if /data/adb/su can change at any time.
[SuperSU] Daniel V.:
Thanks a lot, Chainfire! I succeeded to get root access and I learned something new!
[SuperSU] Chainfire:
If you don't mind me asking, what do you use busybox for that isn't available in toybox/toolbox? Or is it just a convenience thing? Do you want it for specific apps that need it, or your own terminal / adb shell / boot scripts usage?

I used to be very annoyed with the lack of options in toolbox (back when 'cp' wasn't even a thing, we had to 'cat' with redirection) but since say 5.x it hasn't been a big issue (for me), and getting better all the time.

With busybox most of my experience is that it breaks a lot of things. So many errors across all my root apps have eventually been traced back to incompatible busybox installations that I've just grown completely averse to it. FlashFire does use it internally, but it has its own copy, that it keeps out of the path.

We should have a per-app busybox setting :D

Oh yeah I did misunderstand. In TWRP those indeed do not exist, and you would currently use /data/adb/su, if /data/su.img isn't available.

There isn't a completely reliable way, as /data may not even be available from TWRP, and if file-based encryption is used, /data may be there but /data/adb may be encrypted.

Assuming /data is decrypted though, since v2.82 SR2 there's a supersu_is_here file. If you don't want to hardcode /data/adb/su (I'd certainly advise making it a variable in any case), you could use that to locate the base folder:

find /data | grep supersu_is_here | sed 's/\/supersu_is_here//g'
[SuperSU] srqrob:
Just curious why you flashed the full OTA as opposed to applying the factory image update?
[SuperSU] zelendel:
Most flash the full update as the partial update normally causes issues.
[SuperSU] Viggen66:
To manually install root on a rom, I need to copy these files to

/system/xbin/su

/system/xbin/daemonsu

/system/xbin/supolicy

and add on the kernel?

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

class core

oneshot

If so, where can I get the most recent files for the xbin folder?
[SuperSU] Ofthecats:
[MENTION=631273]Chainfire[/MENTION]

Would you consider making an aroma installer for SuperSU with a choice for systemless and sbin options?
[SuperSU] Chainfire:
http://su.chainfire.eu/#embed-rom

No. AROMA is not supported on all the platforms SuperSU is, the latest binary does not match the latest sources, etc. I am working on a different solution though, and if you're rooted already, I hope to bring the options configuration to a FlashFire dialog as well at some point.

That being said, there used to be an AROMA version floating around here somewhere. You could start there and extend it if you're up to it.
[SuperSU] Viggen66:
Chainfire,

Thanks for your reply, I will follow the guide to embedded root.
[SuperSU] TonikJDK:
SR2 installed on my Pixel XL. No issues, everything works. Had to reflash custom kernel, but that is to be expected.
[SuperSU] srqrob:
Interesting. For months I've been running the modified (remove the -w) flash-all.bat from the downloaded Marlin Factory Image, then flashing SuperSU in TWRP without any issues. It seemed simple and foolproof to me. Just lucky so far?
[SuperSU] xdamami:
Thanks King!!! Working well tried SGS5 flashed with Fusion TWRP 5 time reboot no any binary issue. really big Thanks Chain fire!!!
[SuperSU] Blac Caesar:
v2.38 working fine here. Nexus 5, Cataclysm ROM
[SuperSU] Bhaskara Rao:
V 2.38 working fine on Samsung Tab 2 p3100 on Android-Andi's SlimLP.
[SuperSU] goran_oh:
V2.38 working fine lg g2
[SuperSU] darkrevlis:
i can't press button for get grant permissions with v2.38

Galaxy s4 i9505
[SuperSU] Johnny camaro:
Ter info:

Still having some issues after a reboot using the latest beta, rebooting again gives me root permission.
[SuperSU] Johnny camaro:
S5 900f
[SuperSU] Chainfire:
When you have this issue, try running this:

adb shell daemonsu --reload

... and see if that fixes the problem

I'm finding it very hard to reproduce a failure with the new beta, but I admit it's still possible.
[SuperSU] Johnny camaro:
Okay thanks,

When its happened again I will give it a try.
[SuperSU] naudmick:
disable Knox Agent in tatanium backup ?
[SuperSU] NZgeek:
Search this thread or the main dev thread for "tapjacking protection". Your issue has been talked about so many times it's not even funny.
[SuperSU] canodroid15:
Disable all things Knox in Tibu
[SuperSU] darkrevlis:
Thanks mate, working now
[SuperSU] farid993:
Still get "no Su binary" error in SuperSu and broken root with Beta 2.38 and SGS5 Lollipop and TWRP 2.8.2

5 times restart and no chance yet. I flash 2.38 over 2.37. Wipe is necessary for Beta 2.38?

Edit:

now it is ok. I have a question. Should i wait few minutes after reboot to get root access or right after reboot i must have root access in Lollipop? I think in past i had root access right after reboot.
[SuperSU] scanno:
I am having this issue with Omni 5 (manta and opo). Will try to reload daemonsu to see if that helps. Also will try to get you some logging.
[SuperSU] _alexndr:
Thanks [MENTION=631273]Chainfire[/MENTION], I am very glad with this update.

It occurs definitely rarer in 2.38 but still occurs (approximately 1 times per 10 reboots in my case)

I just tested it. If it happened, then I typed in Terminal Emulator:

daemonsu --reload

... and it works - I got root permissions without reboot :)
[SuperSU] wanam:
Reproduced and fixed 2 times with the command:

adb shell daemonsu --reload
[SuperSU] scanno:
does not work here :(
[SuperSU] MattyDip:
Same problem.:confused:
[SuperSU] Chainfire:
Still looking at it. Reloading the daemon is not the correct fix though.

For those interested, what happens is that during boot up an SELinux policy reload (this one caused by the firmware, not SuperSU) randomly causes system calls to 'blackhole'. They don't return an error - they don't return at all! The process making the call gets stuck, and this makes it very difficult to deal with.

I'm also not sure if this is a bug in the Samsung firmware that will not occur in other 5.0 firmwares. It may well be the case this problem ceases to exist in the next Samsung firmware, so I'm not sure how much work I should put into finding and fixing the issue. On the other hand, if other 5.0 users are having the same issue, it becomes structural and it must be fixed. It's hard to see if others are experiencing this very same issue though, as the same symptoms on different devices/firmwares often have different causes with apps like SuperSU.

EDIT: Be sure to check out the latest SuperSU BETA versions (2.39 at time of this edit) and see if that fixes things!
[SuperSU] TonikJDK:
He misunderstood your original post. He thought you were flashing the small downloaded OTA. Your way is good, and how I do it.
[SuperSU] chazall1:
SR2 is functioning great.

Thanks you for your work.