yashsingh1/xdaforums huggingface dataset:
[SuperSU] karthikrr:
I wonder if anybody here could point me in the right direction to learn more about this... Its been a while now, but 10-12 years ago, I used to 'play' with Slackware Linux and compile random kernels just for the heck of it. No, this does not make me an expert of anything, just means I am adventurous enough to want to learn :)

I have a SM-P607T (Note 10.1 2014 edition LTE) that got a long overdue 5.1.1 update last week and figure if there is a good resource where I can read more about rooting it 'manually', then I can try to learn and contribute. Yes, I already saw the other bit on the WIP thread too, about extracting sepolicy and replacing it and so on. I just want to read more on the subject before I start messing around, and do not know where to begin. If somebody more knowledgable can point me in the right direction, even if it is just to tell me what search terms to use, I would appreciate it.

In the meantime, I also noticed elsewhere that Chainfire said to provide recovery.img so he could take a whack at it. Does this offer still hold? If yes, and if nobody else has done it yet, can I pull the recovery.img from the OTA update and provide it here? Again, just some suggestions on what to look for will be appreciated.

Oh and Chainfire (and others!), THANKS for all your work over the years :)

Karthik
[SuperSU] Chainfire:
You can ignore all lines that contain "permissive=1", these are just warnings. A few other ones are not related to SuperSU or your app.

Both of these come down to the same audit:

[ 40.633058] type=1400 audit(1444332049.447:19): avc: denied { transfer } for pid=274 comm="servicemanager" scontext=u:r:servicemanager:s0 tcontext=u:r:init:s0 tclass=binder permissive=0

I will investigate these further. This does look like a basic failure that should be handled by SuperSU. I will review this for the next update. Feel free to note other basic system commands that fail, after you have done the following:

supolicy --live "allow servicemanager init binder transfer"

Please confirm if this is the case or not, this works for me.
[SuperSU] Chainfire:
Generally speaking, that offer stands, but right now I am way too busy with updates on things related to 6.0. Besides, on Samsung 5.1.1, just the recovery won't cut it, you probably need a modified boot.img per my instructions (for devs). I will automate that process shortly if it ends up being the way to go, but it is too soon for that (I also advise others against automating this right now). There are plenty of people around here who know enough to do this, hopefully one will offer a hand.
[SuperSU] karthikrr:
Yup, I gathered from what bits and pieces I read that 5.1.1 was not too straightforward. One set of readings led me to believe that the kernel needs to be recompiled with certain things disabled. But, if I understand your advice to somebody else here, to simply disable things (permissive kernel? I may be COMPLETELY wrong, but don't worry about correcting me. Still a lot I have to read, will figure this out in time) is not the best way to be doing things.

Your sepolicy instructions are different from this and seem to be more akin to replacing the nasty bouncer with one who is nice enough to allow SuperSU to pass through. I am tempted to start playing around with your instructions and learn, but thought it best to wait till somebody reassured me that my tablet would not have a premature death if I messed around with this.
[SuperSU] garyd9:
No luck. Damn. The sepolicy seemed to be modified successfully, and I was able to boot with the modified boot image, but I'm encountering a very Odd issue (that I've never seen before) with this Samsung Note 5 device. I don't think it's related to the su, however, so feel free to skip the rest of this message.

(On the other hand, being that you've had so much experience fighting samsung issues, you might have some insight)

Basically, it APPEARS that if anything modifies the system partition, the device boot-loops. Install TWRP, it works. I can even install either the stock boot image OR a modified boot image (stock kernel with ramdisk's sepolicy modified), and it works. However, if I allow TWRP to mount /system as R/W, (or just let Philz run at all), then the normal boot process boot-loops after the logo, but before the boot animation.

So far, it appears that people have only been able to modify the system partition by completely replacing the kernel with something recompiled and neutered.

(When I get more time, I'm going to try modifying the kernel's ramdisk to perform some test writes to /system to see if that also causes the boot loops...)

Edit:

A bit of browsing in the ramdisk shows a mount option for /system as "support_scfs" I have no idea what that is... but searching XDA for that leads me to believe that removing that mount option might resolve my issue. (I just HATE mucking with something when I don't understand what/why/how.)

Edit 2:

Yep, that fixed it. I now have a "stock" Note 5 kernel booting and working with a modified sepolicy and fstab on the ramdisk. As if you haven't heard it enough, thank you again, [MENTION=631273]Chainfire[/MENTION].

Any suggestions on a suite of tests to validate both root is functional AND that sepolicy is working properly in enforcing mode?
[SuperSU] Cwoomer:
Can't seem to edit build.prop using elementalx and supersu 2.51 beta. Been reading everywhere can't figure it out. I have root access but when I open build.prop in root explorer text editor it says "root explorer was unable to read this file. Please make sure your phone is properly rooted" any ideas?
[SuperSU] jonrodz:
Does 2.51 works on lollipop? I havent encountered a response to that.
[SuperSU] Mayday_XL:
Yes

*** Mayday@Nexus 5 ***
[SuperSU] palmbeach05:
2.51 is the same as 2.50, but with the added support of x86. Its already been reported that 2.50 works on 4.4.4 and up. Same goes for 2.51

---------- Post added at 11:43 PM ---------- Previous post was at 11:40 PM ----------

Read the past few pages or the xda article about android 6.0 and the root issues (not referring to actually rooting, but other apps not being able to recognize root). We're only a few days into it, its to be expected. Relax and wait.
[SuperSU] MG386:
Root explorer seems to have /system rw access if you set SeLinux to permissive...
[SuperSU] grivad:
I ran into an issue with 2.50 and Titanium which was driving me nuts. It wouldn't recognize root, even though I was getting the toast that it was given access. Couldn't find any reports of the same issue. Ends up it was the option to use the system Busybox instead of the built-in one; once I unchecked that, everything worked perfect.

As a sidenote, before I knew that 2.50 was made for Marshmallow and flashed it, I had flashed and was using 2.46, first with ElementalX then with gerar_f's modified stock. I didn't have any problems at all.
[SuperSU] Ja_som:
On my N5 I have no issue with Titanium Backup and some other apps, but Wakelock Detector, Call Recorder and Power Toggles (restart option) are not working with Chainfire's boot image. And before (on dev. previews, and one day on final version of M) I used Despair kernel and I had no issues.

I sent emails to devs of Call Recorder and Power Toggles, but I also want to say it here, that some apps have issues with Chainfire's boot image...

:(
[SuperSU] palmbeach05:
Personally I didn't know about the versions after 2.46 until a few weeks ago when the stagefright vulnerabilities came out and I tried applying the patches. I ran into a root issue and stumbled across these betas. It was 2.49 when I found it. Flashed that update and things were fine.
[SuperSU] springer.music:
It looks like the issues with some root apps not working are somewhat related to SeLinux.

I temporarily switched SELinux to "permissive" using SELinuxModeChanger and Call Recorder, Zip Me, etc started working fine.

I understand that running the system with a permissive SELinux is not ideal but as a temporary measure I can switch it to permissive only when I need to run a specific app and revert it to enforcing afterwards.
[SuperSU] djsubterrain:
Hi [MENTION=631273]Chainfire[/MENTION], is there any chance of you adding in a boot image for the Nexus 4? As you can see from this post, one of the Google Devs (Dmitry Grinberg) released a boot image and system image for the Nexus 4 for Marshmallow but obviously there is no root possible so far.
[SuperSU] Ja_som:
Thanks, so I have a question...

What is better, use kernel like ElementalX or Despair, or use Chainfire's boot image and SELinuxModeChanger to get Call Recorder and other apps working?
[SuperSU] linkish:
I hate to dumb down this thread, but I'm having a bit of an issue rooting Marshmallow on my Nexus 6 with Chainfire's method. Hopefully someone patient enough can help me out.

I've followed the instructions (I flashed the factory image of 6.00 when it was first posted) I have the latest TWRP installed, downloaded and flashed the modified boot.img provided via ADB, and attempted (many, many times) to sideload the SuperSU 2.50 beta provided. Everything looks okay, every time. But it fails time and time again to give me root access. This has resulted in a sad Mr. Linkish.

In the first place, after I sideload 2.50, I get the "your device does not appear to be rooted" message in TWRP. I've chosen both options (Do Not Install and Swipe to Install) to proceed and reboot my phone. Every time, no SuperSU in the app drawer. If I proceed to download it from the Play Store, I open it and get the message about the binaries not being installed.

I wouldn't exactly say I'm at my wits' end at this point, but like a big dummy, I've been trying this process over and over, to no avail. There has to be something I'm missing; I'd be really grateful of one of you kind folk could lend a hand.

Cheers in advance.
[SuperSU] anakdayak:
Hi currently i'm on z1 stock deodex 5.1.1 with supersu 2.46.Is it possible for me to flash the beta 2.51?
[SuperSU] haseoxth:
Depend on you prefer a custom kernel or not, by using SELinuxModeChanger app you can already set SELinux mode between enforcing and permissive at any time.
[SuperSU] Ja_som:
I do not use any feature of custom kernel, therefore I ask what is better. OK, so I install SELinuxModeChanger, thanks...
[SuperSU] haseoxth:
Yes it's ok. But not necessary for android version below 6.0
[SuperSU] anakdayak:
Ok mate tnx for quick reply.I just stay with 2.46 then.
[SuperSU] Chainfire:
If you are having trouble with some apps with SELinux enforcing, the correct thing to do is mentioning the apps, and posting the SELinux audits generated while running that app (while in enforcing mode, not permissive).

Start logging using adb logcat as follows:

(windows)
adb logcat | find "audit" | find /v "permissive=1"

(mac/linux)
adb logcat | grep "audit" | grep -v "permissive=1"

This should already log a couple of lines. Then when you start the app and do something that doesn't work, more lines will be logged. Copy/paste those lines here inside a

or [quote] block.

You have the power to help resolve these issues, use it.

[MENTION=3168665]Cwoomer[/MENTION] [MENTION=4134001]MG386[/MENTION] [MENTION=328776]grivad[/MENTION] [MENTION=5201515]Ja_som[/MENTION] [MENTION=3322890]springer.music[/MENTION]
[SuperSU] grivad:
Are you sideloading via ADB? Don't do that. Flash the SuperSU .zip from within TWRP. Copy/download the zip to the internal storage on the phone and flash it. Make sure you have a modified kernel that allows rooting for Marshmallow first, before you flash the .zip.

---------- Post added at 03:16 AM ---------- Previous post was at 03:11 AM ----------

Will do! I didn't know it was a SELinux issue and assumed it was quirkiness with TiBackup due to Marshmallow being so new and iffy root.

I'll flip the setting again to see if I can reproduce the issue, and if I can, will log and report.
[SuperSU] PeQuEsan:
That's exactly what I think. Thanks Chainfire for that adb logcat commands. I'm facing problems restoring apps with the very well known app Titanium Backup (up to date), which I don't have if I set SELinux to permissive... I've notified Titanium Backup devs my problems, but as it's a so very well known app I'm a little bit frustrated that I didn't find similar reports around the internet.

I attach my log when trying to restore an app. The relevant log line I think is the one that includes "install.apk" in it.

Just FYI, if the app is allready installed, then TB restores it (with data) with no problems.

bye!
[SuperSU] Chainfire:
So, the failures I see in this log are not generic in a way that SuperSU should fix them. I see failures reading from /proc as untrusted_app, which is to be expected. Not sure what is going on with the install.apk thing, but it looks like a policy TiBu itself should circumvent, or perhaps change the method of installing the apk. It seems they are mixing contexts in the wrong way, I'm surprised this worked at all at some point.

Actually, this is good!

Please do this:

adb shell
su
supolicy --live "allow servicemanager init binder transfer"
exit
exit

And see what problems persist. If they do, post new audit logs.
[SuperSU] Cwoomer:
Delete

---------- Post added at 07:17 AM ---------- Previous post was at 07:14 AM ----------

While I am quite relaxed and have read all those items and articles. I was merely asking if there was an alternative. I have since used es file explorer to gain r/w access without having SeLinux set to permissive. Thank you

---------- Post added at 07:20 AM ---------- Previous post was at 07:17 AM ----------

Thanks for the help. I was trying to not change SeLinux to permissive. I found that esfileexplorer works to have r/w access to system while keeping SeLinux intact.
[SuperSU] Ja_som:
After this, Wakelock Detector and Power Toggles works, Call Recorder not:

iMac-Janci:~ ja$ adb shell
shell@hammerhead:/ $ su
icy --live "allow servicemanager init binder transfer" <
supolicy v2.50 (ndk:armeabi-v7a) - Copyright (C) 2014-2015 - Chainfire

Patching policy ...
-allow:servicemanager:init:binder:transfer=ok
- Success
root@hammerhead:/ # exit
shell@hammerhead:/ $ exit
iMac-Janci:~ ja$ adb logcat | grep "audit" | grep -v "permissive=1"
10-09 13:30:20.440 839 2245 I BootReceiver: Copying audit failures to DropBox
10-09 13:30:20.447 839 2245 I BootReceiver: Copied 8285 worth of audits to DropBox
10-09 13:33:13.082 197 197 W servicemanager: type=1400 audit(0.0:20): avc: denied { transfer } for scontext=u:r:servicemanager:s0 tcontext=u:r:init:s0 tclass=binder permissive=0
10-09 13:33:25.052 4917 4917 W Thread-442: type=1400 audit(0.0:24): avc: denied { signal } for scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:init:s0 tclass=process permissive=0
10-09 13:33:25.202 157 157 I auditd : type=1403 audit(0.0:26): policy loaded auid=4294967295 ses=4294967295
10-09 13:33:41.612 157 157 I auditd : type=1403 audit(0.0:30): policy loaded auid=4294967295 ses=4294967295
10-09 13:34:07.982 5207 5207 W Thread-467: type=1400 audit(0.0:32): avc: denied { signal } for scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:init:s0 tclass=process permissive=0
10-09 13:34:08.082 157 157 I auditd : type=1403 audit(0.0:34): policy loaded auid=4294967295 ses=4294967295
10-09 13:34:14.422 5258 5258 W Thread-468: type=1400 audit(0.0:39): avc: denied { signal } for scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:init:s0 tclass=process permissive=0
10-09 13:34:14.542 157 157 I auditd : type=1403 audit(0.0:41): policy loaded auid=4294967295 ses=4294967295
10-09 13:34:20.932 5304 5304 W Thread-471: type=1400 audit(0.0:44): avc: denied { signal } for scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:init:s0 tclass=process permissive=0
10-09 13:34:21.052 157 157 I auditd : type=1403 audit(0.0:46): policy loaded auid=4294967295 ses=4294967295
iMac-Janci:~ ja$
[SuperSU] Chainfire:
The fix for Wakelock Detector and Power Toggles will be in next SuperSU update.

The fix for Call Recorder is not generic, but this may fix it, from adb shell / su:

supolicy --allow "allow untrusted_app init process signal"

I don't think this is a policy we would want active on a device by default. So if Call Recorder needs it, they need to set it themselves.
[SuperSU] wirelezzz:
I had same problem and started using es file explorer and works perfect now !
[SuperSU] Bubble-be:
This also fixes Llama handling airplane mode:

10-09 13:49:09.975 208 208 W servicemanager: type=1400 audit(0.0:1303): avc: denied { transfer } for scontext=u:r:servicemanager:s0 tcontext=u:r:init:s0 tclass=binder permissive=0
10-09 13:49:11.375 208 208 W servicemanager: type=1400 audit(0.0:1304): avc: denied { transfer } for scontext=u:r:servicemanager:s0 tcontext=u:r:init:s0 tclass=binder permissive=0
10-09 13:49:22.405 208 208 W servicemanager: type=1400 audit(0.0:1305): avc: denied { transfer } for scontext=u:r:servicemanager:s0 tcontext=u:r:init:s0 tclass=binder permissive=0
10-09 13:49:23.545 208 208 W servicemanager: type=1400 audit(0.0:1306): avc: denied { transfer } for scontext=u:r:servicemanager:s0 tcontext=u:r:init:s0 tclass=binder permissive=0
[SuperSU] Ja_som:
Thank you, with that command Call Recorder works. So I will contact Call Recorder dev, and I send him link to your post.

Thank you again ;)
[SuperSU] flar2:
Question for Chainfire or other devs with apps on the Play Store:

Does Google care if you make supolicy calls from your app?

I've been burned before by messing with selinux in an app and now I'm scared to do anything. I have an app that needs to change something with supolicy, and I've refrained from putting it on the Play Store because I can't afford another strike against my dev account.
[SuperSU] GamaX320:
the latest supersu included busybox ? Bec when I launch Kernel Auditor it ask me to install busybox
[SuperSU] haseoxth:
Always need to install busybox by yourself.
[SuperSU] androcraze:
http://xdaforums.com/showthread.php?t=1929852

I install the "Stericson" version.
[SuperSU] linkish:
A kernel like ElementalX 3.01? Unfortunately I've tried that as well. And tried it again before I came back here to reply, just for good measure. Still getting the same outcome. Is there anything else you think I should try?
[SuperSU] Chainfire:
Yup, looks like something Root Explorer needs to fix internally.
[SuperSU] altitud63:
So, I have stock 6.0 on my N6 with Hellscore b7-M and SuperSU 2.49, if I want install the new version of both (SuperSU and Kernel), Should I have to first flash the modified boot.img, then the new kernel and later the SuperSU 2.51? Thanks in advance.
[SuperSU] skvalex:
Call Recorder actually does it. But it doesn't work.

1. Policy applied:

# supolicy --live "allow untrusted_app init process signal"
supolicy v2.50 (ndk:armeabi-v7a) - Copyright (C) 2014-2015 - Chainfire

Patching policy ...
-allow:untrusted_app:init:process:signal=ok
- Success

2. It's there:

# supolicy --dumpav | grep "untrusted_app-->init (process)"
[AV] 1943: ALLOW untrusted_app-->init (process) [getcap setcap sigstop execheap setfscreate transition fork signull setrlimit getattr getsched setexec getpgid execstack rlimitinh setsockcreate [B]signal[/B] execmem]

3. But SELinux still doesn't allow the app to send a signal:

<36>[ 1490.465361] type=1400 audit(1444435101.424:1011): avc: denied { signal } for pid=13302 comm="Thread-176" scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:r:init:s0 tclass=process permissive=0
[SuperSU] bigknowz:
adb command killed

[MENTION=631273]Chainfire[/MENTION], thanks for keeping me rooted. Flashed boot.img and su2.50, root looking good. However, tried to execute in terminal as su

svc data enable

svc data disable

commands are killed

Did some snooping and read that it could be related to root. Is it that or higher security in M? Thoughts?

UPDATE: If you are having problems with TiBu, check preferences and Backup folder location, looks like M changed the directory tree definition. Get TiBu looking in the proper place and you should be all set.
[SuperSU] bshiznit:
[MENTION=631273]Chainfire[/MENTION] is there a te supolicy union file for supolicy for aosp device trees or is this still sufficient? https://github.com/CyanogenMod/android_external_sepolicy/blob/cm-13.0/su.te
[SuperSU] Milamber:
Will this version work with latest CM for Nexus 6?
[SuperSU] USBhost:
Yes!
[SuperSU] grivad:
Yes.. try the custom stock kernel by gerar_f.

And you are flashing SuperSU from recovery, not sideloading via ADB, right?

Not sure what else to try.. it worked first shot for me.
[SuperSU] famewolf:
Is there a mirror for the beta zip? The chainfire site keeps giving me timeouts on downloading 2.51.
[SuperSU] palmbeach05:
Different browser maybe?
[SuperSU] famewolf:
Tried firefox and wget....could be my t-mobile connection I suppose....

famewolf@HP810-135qe:/workarea/android/n5/marshmallow > wget -c http://download.chainfire.eu/742/SuperSU/BETA-SuperSU-v2.51.zip

--2015-10-10 02:24:34-- http://download.chainfire.eu/742/SuperSU/BETA-SuperSU-v2.51.zip

Resolving download.chainfire.eu (download.chainfire.eu)... 5.79.66.53

Connecting to download.chainfire.eu (download.chainfire.eu)|5.79.66.53|:80... connected.

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.

Retrying.

*update* someone was nice enough to send it. Thank you!
[SuperSU] palmbeach05:
I know some ppl run into issues with some browsers and dl'ing from sites, thats why i made the suggestion i did
[SuperSU] Chainfire:
Are you the Call Recorder developer?

Anyway, that is interesting. Probably has something to do with MCS (the :c512,c768 part), I'm not entirely clear how that works yet, but I've noticed some more oddities related to that.
[SuperSU] Miche1asso:
I ask it here because in the stable thread I had little luck. The question is simple:

In Lollipop 5.1.1 with namespace separation enabled in SuperSU, how do I make a public bind mount from a script in /system/su.d?

I assumed that starting from there all mounts were supposed to be public, and that doesn't seem to be the case (su ARM v7 v2.45, but the apk is 2.46). I also tried with "su --master-mount -c mount <...>" and it had no effect at all. It only works disabling the namespace separation.
[SuperSU] skvalex:
Yes, I am.
[SuperSU] Chainfire:
Is there a specific call that generates that audit ? Having trouble reproducing it at will.

Additionally, I'm still not convinced this should even be something you can do. Generally opening up *_app contexts is wrong.
[SuperSU] psygbert:
SuperSU cannot read its own log file when enforcing:

10-10 19:16:27.802 8970 8970 W ainfire.supersu: type=1400 audit(0.0:3640): avc: denied { open } for path="/data/data/eu.chainfire.supersu/logs/L14444757410000.GRANTED.com.oasisfeng.greenify" dev="mmcblk0p42" ino=409578 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0
10-10 19:16:27.842 8970 8970 W ainfire.supersu: type=1400 audit(0.0:3641): avc: denied { open } for path="/data/data/eu.chainfire.supersu/logs/L14444757410000.GRANTED.com.oasisfeng.greenify" dev="mmcblk0p42" ino=409578 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0 tclass=file permissive=0

I tried permitting it via supolicy:

supolicy --live "allow untrusted_app app_data_file file open"

However, it still cannot read the log file after supolicy.

It is actually allowed when looking at the access vector:

[AV] 212: ALLOW untrusted_app-->app_data_file (lnk_file) [append create write unlink ioctl getattr setattr read rename lock open]
[AV] 853: ALLOW untrusted_app-->app_data_file (fifo_file) [append create write unlink ioctl getattr setattr read rename lock open]
[AV] 2451: ALLOW untrusted_app-->app_data_file (dir) [create write ioctl getattr setattr read rename rmdir remove_name add_name reparent search open]
[AV] 3472: ALLOW untrusted_app-->app_data_file (sock_file) [append create write unlink ioctl getattr setattr read rename lock open]
[AV] 5071: ALLOW untrusted_app-->app_data_file (file) [append create execute write unlink ioctl getattr setattr read rename lock execmod execute_no_trans open]