yashsingh1/xdaforums huggingface dataset:
[SuperSU] Chainfire:
This also has to do with MLS/MCS. I've not figured this out yet.

However, I did notice this problem myself before 2.50 release, and added a patch to SuperSU itself. I assume you're using 2.50+, so either the patch is faulty (it works for me, though) or there is something else I've overlooked.

Did you install / symlink busybox by any chance?

Does anybody else have issues reading the logs?

What's the output of (adb shell, su):

ls -lZ /data/data/eu.chainfire.supersu/
[SuperSU] psygbert:
Yes. busybox is installed. It is on /system/xbin. The only symlink pointing to busybox are tools compiled in busybox. e.g. cd /system/xbin; for x in $( ./busybox --list); do ln -s busybox $x; done

root@shamu:/data/data # ls -lZ /data/data/eu.chainfire.supersu/
drwxrwx--x u0_a75 u0_a75 u:object_r:app_data_file:s0:c512,c768 cache
drwxrwx--x u0_a75 u0_a75 u:object_r:app_data_file:s0:c512,c768 code_cache
drwxrwx--x u0_a75 u0_a75 u:object_r:app_data_file:s0:c512,c768 files
drwxr-xr-x root root u:object_r:app_data_file:s0:c512,c768 logs
drw------- root root u:object_r:app_data_file:s0 requests
drwxrwx--x u0_a75 u0_a75 u:object_r:app_data_file:s0:c512,c768 shared_prefs

I am using SuperSU 2.51.
[SuperSU] Chainfire:
Sorry, my mistake. Found, fixed.
[SuperSU] skvalex:
Created a sample project for you. See howto.txt.
[SuperSU] Chainfire:
Right, so this issue is due to

categories

. CallRecorder runs as u:r:untrusted_app:s0:

c512,c768

.

The daemon runs as u:r:init:s0:

c0

, where c0 is implicit.

You can't signal c0 from c512,c768. This is not a root issue. Nor is it a policy issue in the sense of 'allow' rules. In fact, I'm not currently sure how you could open this up, as I haven't worked much with categories before myself.

The suggested policy however, is still odd in itself, untrusted_app being able to signal init is a strange policy in the first place. If you just want to kill the daemon, why not just run the kill command through su? Seems to me that if you do that, you don't have to modify the policy at all, which is always preferred.

That being said, from v2.52 onward, you could start the daemon like this:

su u0_a123 --context u:r:init:s0:c512,c768 -c /path/to/daemon

Combined with that policy, it will work. I guess that because init is a permissive context, the c512,c768 will not further restrict what the daemon can do, but you will need to test that.
[SuperSU] Chainfire:
v2.52 available

Just uploaded v2.52. I would recommend all M users to update as it contains some important policy changes that affect a number of root apps.
[SuperSU] torecdude:
Awesome!

Should we test it with your modified boot.img? Or with a custom kernel?
[SuperSU] bigknowz:
svc command works with 2.52. Thanks
[SuperSU] linkish:
Just tried that kernel. The song remains the same: no root access. And yes, I flashed both the kernel and SuperSU from TWRP.

At this point I'm just plain stumped. I don't know who else to turn to for help or information, as I followed all directions faithfully. The kernels take to the process just fine, but I just cannot seem to get SuperSU installed. I guess I'll just have to sit on my hands for the time being.

Anyway, thanks for your time, I really appreciate it.
[SuperSU] osm0sis:
[MENTION=631273]Chainfire[/MENTION], I just noticed the options under Cleanup in the app still don't restore /system/bin/install-recovery_original.sh to /system/bin/install-recovery.sh; any chance of a fix for that making it into the betas here? Thanks!
[SuperSU] bigknowz:
Last try?

Try installing busybox as well, and then follow the instructions from eng.stk

http://xdaforums.com/nexus-6/orig-development/kernel-t3019015

extract boot.img from Chainfire's zip

flash boot.img in twrp

flash SuperSU

reboot

see if busybox installed and rooted
[SuperSU] USBhost:
and if that fails

I can always make the init to not enable selinux

PM me if want it [MENTION=2699991]linkish[/MENTION]
[SuperSU] Srandista:
[MENTION=631273]Chainfire[/MENTION] Wakelock Detector working again, thank you!
[SuperSU] matt1515:
LMT still not getting root access on enforcing. Back, home, and menu not working on chainfire's newest kernal. Works when you change it to permissive. Must still need an update to the app.
[SuperSU] billyx1:
Is restore of call history, wifi-networks, bluetooth-settings, ... working for you? It doesn't work for me.

---------- Post added at 01:55 AM ---------- Previous post was at 01:01 AM ----------

Thanks for your great work.

Just some short questions. I used your first version of patched kernel on my encrypted Nexus 5 (which unfortunatly did a factory reset on my phone).

- If I update to 2.52 do I need to update the boot.img?

- Will it produce a factory reset this time?
[SuperSU] Ingenium13:
You should probably use the new boot image. I used the newer version on my encrypted Nexus 6 and it didn't wipe anything.

Sent from my Nexus 6
[SuperSU] Ketawa:
I rooted my Nexus 5 on Marshmallow using the Chainfire modified boot and SuperSU v2.52. Along the way I reset my personal data and now I'm trying to restore everything using Titanium.

Restoring SMS/MMS and my call history worked fine, but I am unable to restore any apps. Neither app only or app + data work. I tried that logging method and got this. Can anyone make sense of it?

10-10 20:17:19.835 9558 9558 W app_process32_o: type=1400 audit(0.0:43): avc: denied { write } for name="system@framework@boot.art" dev="mmcblk0p28" ino=105876 scontext=u:r:shell:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file permissive=0
10-10 20:17:19.885 9558 9558 W main : type=1400 audit(0.0:44): avc: denied { write } for name="arm" dev="mmcblk0p28" ino=105875 scontext=u:r:shell:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=dir permissive=0
10-10 20:17:26.945 9650 9650 W app_process32_o: type=1400 audit(0.0:45): avc: denied { write } for name="system@framework@boot.art" dev="mmcblk0p28" ino=105876 scontext=u:r:system_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file permissive=0
10-10 20:17:26.995 9650 9650 W main : type=1400 audit(0.0:46): avc: denied { write } for name="arm" dev="mmcblk0p28" ino=105875 scontext=u:r:system_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=dir permissive=0
10-10 20:17:27.005 9651 9651 W app_process32_o: type=1400 audit(0.0:47): avc: denied { write } for name="system@framework@boot.art" dev="mmcblk0p28" ino=105876 scontext=u:r:shell:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file permissive=0
10-10 20:17:27.055 7414 7414 W Binder_3: type=1400 audit(0.0:48): avc: denied { open } for name="install.apk" dev="mmcblk0p28" ino=187348 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0
10-10 20:17:27.065 9651 9651 W main : type=1400 audit(0.0:49): avc: denied { write } for name="arm" dev="mmcblk0p28" ino=105875 scontext=u:r:shell:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=dir permissive=0
10-10 20:17:27.475 9675 9675 W Thread-385: type=1400 audit(0.0:51): avc: denied { unlink } for name="install.apk" dev="mmcblk0p28" ino=187348 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0
[SuperSU] occtec:
No just flash latest SuperSU in recovery, make sure you are using latest twrp. No need to update boot.img unless you have encrypted device. Will NOT factory reset but as always recommended just run a backup of your current setup..
[SuperSU] billyx1:
But I have an encryptped device?!?
[SuperSU] occtec:
Then yes flash latest boot.img but be sure to backup first.. It shouldn't wipe your device
[SuperSU] linkish:
Miraculously, this actually worked! I've got rhythm, I've got sunshine, and I've got root!

A thousand thank yous for pointing me in that direction. I'll sing your praises in Valhalla.
[SuperSU] ANDR01DN00B:
Can someone please help me out? I've been trying to get the latest v2.5+ updates to flash, but I've always bootlooped. Can someone guide me through the process of a clean install of a ROM and the SuperSU v2.5 update and boot img? Is it:

1)boot.img (in fastboot)

2)ROM zip

3)SuperSU

4)Kernel

Thanks in advance!
[SuperSU] koolgay:
thank you ------------------ mark----------------
[SuperSU] ashyx:
As far as im aware TB requires a permissive kernel to work not just root.
[SuperSU] skvalex:
No, I don't need to kill the daemon. This is some kind of communication between the app and the daemon.

Seems like it works. Thank you.
[SuperSU] koboltzz:
sorry my fault
[SuperSU] Ketawa:
Yeah, I'm not familiar with all this stuff but I used SELinuxModeChanger to change SELinux to permissive and TB restore worked fine after that. Backup works with it in enforcing.
[SuperSU] StupidIdea:
[MENTION=631273]Chainfire[/MENTION] Thanks for the v2.52. My apps were failing with v2.50 but works with v2.52 after some tinkering.

With V2.50 system services were not returning binder (I think some policy was preventing that for u:r:servicemanager:s0 but I didn't save the log at that time).

Anyway it works again with 2.52 so thank you for the good job once again.
[SuperSU] githyanki:
Make sure you have updated boot.img, there's no version number. Earlier one would bootloop if you were encrypted.

Did you update bootloader and radio earlier?

Some roms and kernels aren't compatible yet. Check with ROM maker to see what they recommend. Since you didnt say gapps, I will assume it was a stock rom. Try with the included kernel first.
[SuperSU] marinierb:
Shouldn't that be:

1) ROM zip

2) boot.img (the modified kernel)

3) SuperSU

???
[SuperSU] ANDR01DN00B:
Haha yeah I figured that out. Thanks!
[SuperSU] TR2N:
Hi guys, just for clarification... I am on Stock M right now. When I flash the modified boot image and SuperSU, does it wipe anything on my current system?

Thank you!
[SuperSU] torecdude:
It might, as chainfire worn. Check OP. Take it safe and make a backup.
[SuperSU] MaximKat:
Is there a boot.img for Nexus 9 (flounder) anywhere?
[SuperSU] Srandista:
Nexus 9 is Volantis.
[SuperSU] Chainfire:
Thanks, I think I got this. Check v2.12 when its released later today or tomorrow or so.

You'll still have to flash that other ZIP first on a clean install probably, due to the odd way of starting daemonsu on your device. Not sure yet if I'm going to build in that workaround or not.
[SuperSU] Chainfire:
v2.12 released

See the first post of this thread for the link to the download, and to the changelogs

Lots of under-the-hood updates (preparing for L release) as well as fixes. Kindly test on all your devices and Android versions again. Some heavy SELinux hacking is going on, so behavior between <4.2, 4.2, 4.3, 4.4, L, and latest AOSP builds may differ. Sooner we find the issues there the better, hoping for a Play release over the next few days if not too significant issues are found (which of course, there will be)
[SuperSU] JulianJenner:
2.12 works correctly on LGE-P760 (OPTIMUS L9) CM11 by Artas182x

LGE-P760, Artas's cm11 build 4.9.13
[SuperSU] DjDiabolik:
http://xdaforums.com/apps/supersu/2014-09-02-supersu-v2-05-t2868133

I can use flashify for upgrading my 2.02 stable?? or it's no safe to upgrade?
[SuperSU] Megaflop666:
No problems to report on SuperSU Pro 2.12 beta:

Note 3 bobcat rom, shinto kernel

Note 3 tweaked rom, ael kernel

S5 xtrestolite rom, ktoon kernel

S4 rooted stock, blaze kernel

Nexus 7, clean room, elemental x kernel

Edit: works perfect on galaxy gear, null ROM
[SuperSU] Pkt_Lnt:
Samsung Galaxy S4 Active GT-I9295 Interntional AOSP 4.4.4 ROM works fine.

Goggle Nexus 7 2013 Stock ROM works fine.
[SuperSU] Frank Westlake:
2.12 OK on:

- Note SGH-I717 4.0.3 Permissive

- Note3 SM-N900V 4.3 Permissive

- Note3 SM-N900T 4.3 Enforcing

Again on the 900T a "#" notification I could not get to quickly enough to read. By the time "touch" was responding and the notification list opened I only had enough time to read "SuperSU", then it cleared.

I did read the Toast this time -- something about SuperSU being restored.

ADDED:

The Notification and Toast have only been on the first boot after installation through recovery.

Frank
[SuperSU] Rlumby:
No issues on HTC M8 using Sinless ROM and kernel.

S off and unlocked.
[SuperSU] HorstiG:
SuperSU 2.12 + Galaxy S3 + Liquid Smooth KK 4.4.4 + Boeffla Omni Kernel = 100% fun.
[SuperSU] skidaway:
All is working fine here with the update.

SuperSU 2.12

SlimKat 8.2

Nexus 4 mako
[SuperSU] Aaahh:
2.11, su stops working on oneplus one

Also, I'm not receiving the broadcast.. I tested it by sending it out with adb and I received it, but your app isn't sending it...
[SuperSU] Pkt_Lnt:
Try 2.12 there are many changes, see post #1 and #2
[SuperSU] Mariner_1712:
2.12 operational on xdabbeb's 2.1.0. ROM (LG G2), will update when I flash to 2.2.0. tonight or tomorrow.
[SuperSU] greyhd:
2.12 working on LG G2 running xdabbeb 2.2 ROM. Thank you for the great work and updates.
[SuperSU] shekinahsmoke:
I'm on liquid smooth 10/2. D2lte Sprint. When I try to press the grant button during the prompt it didn't work. Button unable to press
[SuperSU] Chainfire:
Have you tried disabling tapjacking protection from settings?
[SuperSU] Chainfire:
(1) try the latest version

(2a) if the stop is crash, provide a logcat of it

(2b) if the stop is not a crash, describe in more detail what is happening

(3) comments for the beta version go to the beta thread (just moved it here)

Should not have to be saying this to a dev
[SuperSU] shekinahsmoke:
That fixed the issue. Thanks!!
[SuperSU] MaximKat:
Ah. Weird. The stock bootloader is called bootloader-flounder-3.48.0.0135.img - threw me off. Thanks.
[SuperSU] mdamaged:
You're both right.
[SuperSU] Pure Drive GT:
Hey, thanks for your continued support for root on Android, was just wondering, is google making it harder to achieve decent root privileges, as in they don't want rooted devices or are they just unrelatedly changing up things which forces you guys to adapt?

On another note, is there any progress on root without the modded boot? This is by no means an ETA, just wanted to know if you think it's possible or the situation looks rather dire.

Thanks again for your many efforts!
[SuperSU] MassStash:
Yea the Google dood obviously appears to be right. Got cards to add after turning off root, however tap to pay sill errors even with root off and rebooted...

Flo

ElementalX
[SuperSU] RandomPooka:
Thank you. I was a bit busy as can be earlier and wanted to reference this very article.
[SuperSU] Harmveenstra:
On nexus 5 Android M ElementalX kernel 6.01 I seem to lose root after a while, reboot fixes it.. Anyone else experiencing the same problem?
[SuperSU] Frank Westlake:
2.52 OK through TWRP on:

- Note_ SGH-I717 4.0.3

- Note3 SM-N900V 4.3 single user Permissive

- Note3 SM-N900T 4.3 single user Enforcing TWRP 2.8.6.0

And OK through SuperSU normal update on:

- LGL34C 4.4 (TracFone, TowelRoot special code)

Frank
[SuperSU] Joshmccullough:
FWIW, I'm using Cataclysm ROM along with SuperSU 2.50 and Elemental X 6.01; discussion in the Cataclysm forum's led to setting SE Linux to 'permissive, which can either be done through installing a permissive kernel like Elemental, or using some terminal commands found here .

Additionally, some have found that TiBu needs a little 'goosing' in the right direction to find the standard backup folder. Here's a brief set of instructions.

Hope this is helpful in getting everything up and running for MM builds!
[SuperSU] Chainfire:
Talk about permissive has no place in this thread. Why do I need to keep repeating myself?

Next person gets a ban.
[SuperSU] flar2:
All the latest versions of elementalx are enforcing on all devices. Only the initial release on Marshmallow was permissive, before SuperSU was updated to 2.50.

Some custom ROMs seem to require selinux permissive, that is the cause of many bootloops. Please don't report those issues here. Chainfire is trying to get things working with selinux enforcing.
[SuperSU] aXiDroid:
SuperSU root is blocking the phone after encrypting it.

I've installed the Marshmallow on my Nexus 5 with Nexus Root Toolkit, after that I rooted it. I've set up my unlock pattern and when I charged my phone's battery and turned on the encryption of the phone it rebooted, stared encryption process, but after it ended the phone asked me for a password - not for a pattern. After that the only thing I can do is to reset it with NRT once again.

PS: if this was mentioned before, I'm sorry, I don't have a lot of free time and I only did a quick search, but found nothing. Just wanted to warn you about this.
[SuperSU] ngr.hd:
I can confirm v2.52 is causing bootloops on Android One (sprout4) running stock Marshmallow flashed using official TWRP v2.8.6.0
[SuperSU] Ebra92:
Failed to grant root to clean master. Says to check authorization management tab in supersu and adjust CM permissions, and CM is already in the list with granted permission. Nexus 5 running marshmallow with the custom boot image. Tried rechecking CM on list and rebooting, no luck. I wanted to manage start up apps. This is my first time using root. Thx in advance.
[SuperSU] palmbeach05:
More like user failed to read up on the root issues discussed over the past week in this thread which were caused by a major update (release/update to 6.0). Check to see if the devs of clean master have made their app compatible with 6.0 to include being able to gain root access
[SuperSU] doitright:
Regarding 2.50+ sepolicy patch...

I'm looking at the process for generating the patched sepolicy file, and finding myself somewhat unsatisfied. It looks to me like that supolicy command is reading in the target device's sepolicy file, modifying it in some manner, and producing a replacement for it.

It would be much more useful to understand what, exactly, the changes are that are being made to it.

A cursory glance over platform/external/sepolicy suggests a reversion of this as a likely candidate: https://android.googlesource.com/pl...56df32778732aa576e15071bf2736fbbd778b77^!/#F0

That commit also suggests that the chance of being able to implement a useful root on 6.0+ without boot.img modification is practically non-existent.

So at this point, what I would really like to see is this;

1) more transparent description of the changes being made to sepolicy.

2) a "root" where the modifications required are *confined* to the boot.img. I don't see any reason to break the system partition (dm-verity) by root when there is no technical reason that it must.

In addition, it would be nice to see a more console-friendly implementation that didn't depend on an android application providing authorization. This would be useful for remote shell access scenarios where the gui isn't available. I.e., something like a traditional password shadow file.
[SuperSU] MassStash:
Everything great here with latest elementalx and 2.52 on stock mallow on the flo

Flo

ElementalX
[SuperSU] Rakeesh_j:
Is Google actively trying to prevent being able to have root without a modified kernel? If not, what is the likelihood of ever pulling it off?

On the other hand, if the answer is yes, then I suspect it's probably not worth striving for since it would rely on constantly finding new exploits every time there's a new version.
[SuperSU] palmbeach05:
Read. Its been out for a few days and explains the answer to your question. And its an article one can easily SEARCH FOR BEFORE POSTING A QUESTION (xda rule). And best of all, while we're on the xdaforums.com side of things, this article is on this little known site called xda-developers.com.....

http://www.xda-developers.com/a-look-at-marshmallow-root-verity-complications/
[SuperSU] USBhost:
Vary little lol

I almost never go there I'm always on xdaforums.com
[SuperSU] palmbeach05:
Same here, but its always good to check other places on the site. Personally I never knew about Verity until I read that
[SuperSU] IronTechmonkey:
Pardon this shameless post placed so I could find the thread in XDA app. Tx [MENTION=4895937]palmbeach05[/MENTION] for link to M root scoop.
[SuperSU] lePoMo:
+1 on this if possible.

To me, it would be combined with an overlayfs for /system, so that all changes required to /system would actually not touch the system partition.

Can any gurus shed some light on if this is at all feasible?

(I'm not sure if it would help verity, but it could help applying monthly ota updates, if necessary by reverting boot to stock before applying)
[SuperSU] Chainfire:
These two posts are prime examples why working on SuperSU stresses me out.

6.0 has just been released. A lot of these things are still under investigation. All the work until now is simply to make the basics work, and there are still significant issues with those parts. That is priority 1.

Your satisfaction with documentation on what is going on now (and may change completely tomorrow) is somewhere between "the children in Africa" and "Miley Cyrus" on that priority list. It is a complete waste of my time at this point worrying about it.

Whether or not a modified boot.img will be required for root on 6.0 remains to be seen as well. Some avenues of attack are still open, but at least one of those is a one-liner to block, so I won't expect it to live beyond December's security update.

Root confined to boot.img? Well no **** sherlock, there has been talk about this since Lollipop. Again, work is ongoing.

Overlayfs? Sure. But it can't be kernel based, can't be GPL, and the code must be portable enough to work (or be easily ported) to all common Android architectures. I've looked around, but it seems some works needs to be done there first. Before full overlayfs, (*IF* we go boot.img only) a bind-mount solution is more likely the starting point, though this will not protect you from other root apps writing to /system.

Then both of these need to still be easily updateable too, without having to replace the kernels.

In the meantime, changes like these are not applicable to locked bootloader roots (a fairly large portion of users), and we must keep things simple enough that if the exploiters find a hole, it can be used to it's full capacity.

The reason I have not pointed people at this is because after the above posts, I guarantee there's some kernel dev / zip hero working on being the first to do one of the things above, which will break things in new and interesting ways, and will ultimately cause a ****load of compatibility issues that *I* will be blamed for and will have to waste my already scarce free time to track down. It happens every single time. Additionally, app devs will start expecting/incorporating such a setup from the get-go, which just annoys everybody (again) if it needs to change.

I don't think we'll see 'final' (if there were such a thing) solutions to all of the above before Christmas, so just sit back and chill out.
[SuperSU] SamuriHL:
Thank you for your time, [MENTION=631273]Chainfire[/MENTION]. There are many who appreciate what you do for the community. People should be listening to your warnings.
[SuperSU] fhem:
N6 M stock/rooted no sys write perm HELP PLEASE!!!

[MENTION=631273]Chainfire[/MENTION] I can get root but no sys write perm. I have tried everything. I am about ready to throw my phone against the wall. I have wiped all and reflashed (fastboot) numerous times. I have tried diff sequences (sideload/no sideload) and kernels. I am feeling like a comlete noob and I guess this proves I am. :confused: :o LOL. I can install aosp build (Chroma) and all works as should but on stock no sys write perm. When on stock and rooted I can delete from sys using Root Explorer but I cant't copy and paste to sys nor can I flash to sys via twrp. I am at a complete lost. I think I remember seeing a terminal command or adb shell command that fixes this problem but I can't find it again. I have read so many threads I am going blind :crying: and google dosen't help. Thanks in advance for the help. FYI all works good on N9 --- Thanks for your continued help and support.
[SuperSU] palmbeach05:
You can also get read the past few pages about root, and the nice little rant above. Smh, chainfire is right, this thing has only been out a week and everyone expects perfection.