yashsingh1/xdaforums huggingface dataset:
[Nexus 6  General] doitright:
Hmm? They STOLE that from us. Go look at our issue tracker and commit logs, you will see that we were already doing that long before they did.
[Nexus 6  General] abuttino:
You know it was bound to happen.
[Nexus 6  General] Gene Poole:
Well, it's a pretty obvious workaround. I tried this myself a few months back, but couldn't get it to work; couldn't find a reliable way to get a $PATH updated so the userland apps could find it.

I've been using koush's github code ever since KitKat came out. I never did like the way chainfire did things. I'm glad that someone has the ambition to make this a thing again.

Thanks doitright!
[Nexus 6  General] _that:
What are you talking about? This whole thread deals with system-less root, have you read the OP?
[Nexus 6  General] Gene Poole:
I thought systemless root meant that no files need to be written to the system partition.
[Nexus 6  General] topaza:
I followed this thread for a while now and I like the idea of open source root.

I also understood that is an early release which probably is not perfect yet. However it seems to work on Nexus 5 devices...

I am still on lollipop (with cf autoroot) but I would like to upgrade to M. Is there any reason to not use this on productive devices yet? I guess this is still better than flashing any proprietary root thing, where you have no idea what it is doing...
[Nexus 6  General] natemup:
To get Android Pay working, basically. I know Chainfire's systemless method does not work with CM (because of its built-in root, I believe), and I am wondering if this does or will.
[Nexus 6  General] phhusson:
I think it should work as is.
[Nexus 6  General] nicholseric:
When I do it in post-fs-data like this:

# if it exists, mount bind /data/hosts to /system/etc/hosts

on property:gsm.sim.state=READY

#su --context u:r:system_server:s0 -c "mount -o bind /data/hosts /system/etc/hosts"

#su -c "mount -o bind /data/hosts /system/etc/hosts"

mount -o bind /data/hosts /system/etc/hosts

Without su, I get an error in dmesg. When I do it with su, I dont get any dmesg error and I dont get a mount.

[ 23.110235] type=1400 audit(1446497132.122:4): avc: denied { mounton } for pid=1 comm="init" path="/data/hosts" dev="mmcblk0p42" ino=17 scontext=u:r:init:s0 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0

Given I only want root to get my lcd density and hosts file, if this can be done in the boot.img, I dont even need root!
[Nexus 6  General] phhusson:
Yup, you definitely don't need root :P

Something I'm not clear: You're working from source, or from a binary boot.img?

If you're working on a binary boot.img, then you're a client for https://github.com/phhusson/super-bootimg

I've pushed a sample for you: https://github.com/phhusson/super-bootimg/commit/76b108828db4f05d2b6384ea8a4ad49f35578671

(code is not yet factored so it's a ugly copy-paste of install-su.sh but factorising is in the todolist)

Use it by doing sudo bash havealoha.sh original-boot.img

It will create a new-boot.img with the modifications you want (interesting parts are between line 55 and 63), or I hope so at least.
[Nexus 6  General] nicholseric:
Working from source with source from your su, superuser, doitrights patch and repo init -u https://android.googlesource.com/platform/manifest -b android-6.0.0_r1

plus I turned verity back on.

Thanks, I'll take a look.
[Nexus 6  General] phhusson:
Pff no fun :P

If you're from source, you just need to add allow init system_data_file:file mounton; in external/sepolicy/init.te
[Nexus 6  General] natemup:
Good to know! I'll try it out once it's a little more noob-friendly. I don't know the first thing about compiling, Github, etc...

Sent using XDA One
[Nexus 6  General] nicholseric:
Why does it work for root in terminal emulator but not from init? Dont they both use the same context?

Why do you put the lcd prop into default.prop instead of setprop from init? I also added userdebug so I could get multi window!

Wow, so much we can accomplish without rooting!

Here is what I have starting at line 358 in my init.rc:

# set property lcd to 360

setprop ro.sf.lcd_density 360

# turn on userdebug so I can use multi window

setprop ro.build.type userdebug

# if it exists, mount bind /data/hosts to /system/etc/hosts

mount -o bind /data/hosts /system/etc/hosts
[Nexus 6  General] phhusson:
My guess is that calling su from init is totally broken.

I was going to totally remove that future, I didn't expect it could be of any use, but you proved me wrong.

I'll try to see how I'll deal with it.

No special reason, just I'm more used to writing to default.prop

That might sound weird considering my work, but I actually think that mostly noone should need a root.

If root exists it's because proper frameworks/API doesn't exist (yet) in Android for XYZ feature.

We've seen this multiple times: Link2SD is now obsolete (I hope) with M, usb host support (now has proper API), and many others.

But most users only need to be able to change some settings in the ROM, and apktool/xposed + bootimg editor should fit those usages.

My personal usage of root is mostly only for debugging
[Nexus 6  General] nicholseric:
FYI, when I did this, something tripped verity and now I get the corrupted device spash at boot. Flashing factory system and boot did not fix it. Something got written to data that trips verity. Not sure what.
[Nexus 6  General] phhusson:
Mmm I'm not sure which one you're talking about, do you have a screenshot?
[Nexus 6  General] nicholseric:
The red one: [IMG="verity tripped"]http://d.ibtimes.co.uk/en/full/1450840/android-m-boot-verification-system.jpg[/IMG]
[Nexus 6  General] phhusson:
This screen is on bootloader right? I don't think it's verity related, though I can't see why you would get that if you're flashing factory boot.img

Also, you're saying you had verity working, with an AOSP-built boot.img? That's weird, the verity keys in AOSP are different from the ones in factory booy.img
[Nexus 6  General] nicholseric:
You can use the verity_key from factory boot.img when building aosp boot.img. My system.img is factory and thats what has to match what is stored in verity_key.

After wiping data, the corrupted message goes away. Just to verify it was "allow init system_data_file:file mounton; ", I'll do it again. I'll be pleasantly surprised if that didnt cause it. Could have been coincidence.
[Nexus 6  General] phhusson:
Ok, good

I must say that I don't really understand how this flag appears :s It doesn't seem to match Google's documentation...
[Nexus 6  General] nicholseric:
I was able to reproduce this by mounting hosts. This at the end of my init.rc hosed my data partition and now I get the corrupt splash again:

service host_mount mount -o bind /data/hosts /system/etc/hosts

class main

oneshot

"

---------- Post added at 01:50 AM ---------- Previous post was at 01:47 AM ----------

Turns out that it may not the presence of local.prop but I can definitely say that setting my lcd (via init.rc setprop) to 360 tripped safety net and I could not add a card to android pay.
[Nexus 6  General] 31ken31:
It's close to the same crap with now having to pay to S-Off a HTC phone.
[Nexus 6  General] abuttino:
I disagree with that [MENTION=3155542]31ken31[/MENTION].. The developers spend a lot of time working around the bootloader to unlock it.. Jcase and Sunshine is a great example. They break the locks so you can root it. This is something else.

However, this is highly Off topic.
[Nexus 6  General] doitright:
Right.

So what's your point?
[Nexus 6  General] doitright:
The code is very fresh, which means that we have *not* gone over it with a fine tooth comb to get out all the various glitches. Some of it may even be done in a way to just *make it work*. If you are comfortable with that, then by all means, run it. Personally, I do myself. BUT, if somebody hostile figures out an exploit to this "not yet production ready" code, then you forfeit the right to complain about that, because we told you so.

However, bug reports will always be welcome, so if somebody takes over your phone, give us all the details so we can make it better!
[Nexus 6  General] doitright:
There is some confusion expressed in follow ups to this question. The answer is this; I do not believe that ANYTHING will make Android pay work on CM (CM = CyanogenMod), due to the fact that it is so far from a vendor certified Android build that can pass safetynet checks.
[Nexus 6  General] doitright:
Are you sure it was the lcd density line and not the userdebug line? I wouldn't be surprised for a second if userdebug tripped safetynet, since that implies root, AND a permissive su context, even if it is only via adb.
[Nexus 6  General] doitright:
I have a thought... might not actually *be* the data partition that is flagged. The cache partition is used for communications between Android and the bootloader, so it could be a flag set somewhere in the cache partition. If you can reproduce this, try formatting the cache partition, and leaving the data partition as it is.

It would be really nice to get to the bottom of this.
[Nexus 6  General] doitright:
There is definitely something besides verity that is tripping the bootloader to show an error message.
[Nexus 6  General] phhusson:
My binary patching method is not on par yet with doitright's patches

At the moment for a working root it still needs su domain permissive (eng run flag), i can only run dmesg in non-permissive mode.

Your test is interesting thanks.

I guess that you could write selinux allow rules for your own usage, and then send them back to me?

And we could have "build flags" which only pokes needed holes in the selinux policy, depending on a user's need.

As for sepolicy version 30, you have to build libsepol from AOSP and rebuild your tools with it. That's quite annoying :/
[Nexus 6  General] nicholseric:
I used factory recovery to format\wipe cache and still have corrupt splash.
[Nexus 6  General] nicholseric:
Safetynet is going to be a big pain. Here is a nice article on it https://koz.io/inside-safetynet/
[Nexus 6  General] doitright:
And the only change you have relative to a working configuration is the dpi change?

Edit: You need to be *extremely* precise when describing tests of this nature. Remember that it is just a ONE BIT difference between yes and no, success and failure, etc.
[Nexus 6  General] doitright:
At least they aren't obfuscating the code.

The part checking if the device correctly communicates with doubleclick.net is interesting. That is a no-spam-blocker check.
[Nexus 6  General] Gene Poole:
Well, today's update, MRA58N, throws a whole new monkey wrench into the works. I'm on a Nexus 5 so I'm not sure if this is new, or pre-existing in the 5X/6P builds, but it seems any tampering with the boot image results in an immediate "Powering Off" message as soon as boot is complete. No explanation.
[Nexus 6  General] phhusson:
Works for me on a GSM/LTE hammerhead, in eng build (aka permissive su domain), fastboot unlocked
[Nexus 6  General] Gene Poole:
Probably me doing something stupid and probably OT for this thread. Taken to PM.
[Nexus 6  General] nicholseric:
That is correct, only DPI.

1. Started with aosp plus your patch (turned on verity by adding verity_key and changing fstab.shamu) lcd and userdebug as a setprop in init.rc.

Android Pay would not work. Boot screen was without corrupt splash.

2. I built boot.img with userdebug removed and rebooted twice.

Android Pay still did not work.

3. I build boot.img again adding userdebug back and took out lcd.

Android pay worked.

4. I built boot.img again with external/sepolicy/init.te allow init system_data_file:file mounton; and init.rc with

service host_mount mount -o bind /sdcard/Download/hosts /system/etc/hosts

class main

oneshot

The mount did not work but I could do it from terminal as su. It was after the first boot that the second boot was corrupt splash.

5. I built boot.img again without the changes to init.te and init.rc and I factory wiped cache.

Still I get the corrupt splash.

I factory wiped data\cache and the corrupt splash went away.

6. Built boot.img as in #1 but only with lcd setprop 360. No superuser installed.

Android pay would not let me add a card.

7. Built boot.img again without lcd setprop.

Android pay worked.

8. This time I did a backup of my data. Leaving factory recovery in place, I booted twrp and backed up just data to usb otg. "fastboot boot twrp-2.8.7.1-shamu.img" That was getting tiring doing a whole new restore from google each time.

For now, I'll do my lcd but knowing that I can boot a different boot.img to use Android Pay is comforting.

This is where my idea of storing properties in a file on /sdcard/ for parsing by init comes in handy. I keep the same boot.img, just set a property in /sdcard/my.prop The my.prop could have a hash that gets checked by init.rc too. Ideally it would not be named my.prop but some initial random name so future safety net checks could not find it. The hash and random name also prevent other apps from sneaking props in there.
[Nexus 6  General] provolinoo:
does it mean the device won't pass the safetynet check if I install an ad-block like adaway?
[Nexus 6  General] doitright:
Thank you for the details.

Sounds like they are profiling the device's hardware... and since YOUR dpi doesn't match the expected, it deems it messed up.

There are MUCH better ways to protect the file than by hardcoding a hash into the boot partition. Just setting an selinux context on it that it highly protected (something that is world readable, but writable only to su_sensitive) will do the job.
[Nexus 6  General] doitright:
It doesn't mean that it won't pass the check. It means that they can detect it. What they do with that knowledge is for them to know, and us to find out.
[Nexus 6  General] nicholseric:
At some point I had bind mount hosts working from terminal emulator.

Now, I get access denied to netd? And lots of adds. Dmesg:

[ 2244.670795] type=1400 audit(1446574801.528:1741): avc: denied { open } for pid=7217 comm="netd" path="/system/etc/hosts" dev="mmcblk0p42" ino=16 scontext=u:r:netd:s0 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0

[ 2252.882134] type=1400 audit(1446574809.738:1742): avc: denied { open } for pid=7243 comm="netd" path="/system/etc/hosts" dev="mmcblk0p42" ino=16 scontext=u:r:netd:s0 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0

[ 2252.882660] type=1400 audit(1446574809.738:1743): avc: denied { open } for pid=7243 comm="netd" path="/system/etc/hosts" dev="mmcblk0p42" ino=16 scontext=u:r:netd:s0 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
[Nexus 6  General] doitright:
Check the context of /system/etc/hosts (ls -Z), and set the same context to /data/hosts (setcon context)
[Nexus 6  General] nicholseric:
It is already the same context. Am I insane thinking I had this working? I swear I had no ads for a day.
[Nexus 6  General] doitright:
Unless something else in the policy got gummed up, it looks like it should work.
[Nexus 6  General] nicholseric:
Looks like it was an error in the hosts file. I had downloaded this one http://winhelp2002.mvps.org/hosts.txt and then used QuickEdit to change the local host section to match android original hosts. Aparently this does not work well.

Instead I copied from the browser and pasted #cat << EOF > /data/hosts and then edited it with QuickEdit.

This was also needed in init.te:

allow netd system_data_file:file { open read };

No method that I have tried can mount bind hosts from init. Only in terminal emulator.

Here are some other dmesg related concerning looking logs:

[ 87.516611] type=1400 audit(1446592117.201:5): avc: denied { search } for pid=4109 comm=4173796E635461736B202331 name="com.android.chrome" dev="mmcblk0p42" ino=457931 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
[ 87.517287] type=1400 audit(1446592117.201:6): avc: denied { search } for pid=4109 comm=4173796E635461736B202331 name="com.android.chrome" dev="mmcblk0p42" ino=457931 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
[ 87.517497] type=1400 audit(1446592117.201:7): avc: denied { search } for pid=4109 comm=4173796E635461736B202331 name="com.android.chrome" dev="mmcblk0p42" ino=457931 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
[ 87.518100] type=1400 audit(1446592117.201:8): avc: denied { search } for pid=4109 comm=4173796E635461736B202331 name="com.android.chrome" dev="mmcblk0p42" ino=457931 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
[ 87.518324] type=1400 audit(1446592117.201:9): avc: denied { search } for pid=4109 comm=4173796E635461736B202331 name="com.android.chrome" dev="mmcblk0p42" ino=457931 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
[ 87.518520] type=1400 audit(1446592117.201:10): avc: denied { search } for pid=4109 comm=4173796E635461736B202331 name="com.android.chrome" dev="mmcblk0p42" ino=457931 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir permissive=0
[Nexus 6  General] _that:
This is exactly what "permissive" is supposed to do.
[Nexus 6  General] phhusson:
The problem is that you'll be flooded by messages, and init sets the limit of flood to 20 messages in a row.

You'll need to use your own auditd to get full logs. (and i'm not even sure the kernel itself won't throttle)
[Nexus 6  General] doitright:
What you can do is allow kernel:security for the su domain while dev'ing your rules, that way su will be able to set enforcing on/off as needed.
[Nexus 6  General] doitright:
You know what... this really isn't the best place to be posting code details like this. This is more of a discussion board.

What you can do, which would actually be *really useful*, is for each of these rule sets, add an issue to phhusson's Superuser issue tracker. That way they will each be cataloged and can be discussed separately with the objective of including that or a superset of it as a setup option for the scripts.

Things disappear in xda threads.
[Nexus 6  General] nicholseric:
I tried to do an import in init.rc for two init rc files in /data:

+ import /data/init.lcd.rc

+ import /data/init.userdebug.rc

but the only message I get is:

127|root@shamu:/ # dmesg | grep import

[ 2.193064] init: could not import file '/data/init.lcd.rc' from '/init.rc'

[ 2.193092] init: could not import file '/data/init.userdebug.rc' from '/init.rc'

I want the ability to switch between custom lcd and userdebug without changing boot.img's

I was able to get my hosts file mounted after implementing some of the allow's that slifox0 posted.

I take it that the sepolicy in your patch is not aligned with the sepolicy in phhussons super-bootimg? I know this is still early in the project but are there plans to have a single git repo to do either a patch to aosp or a mod to boot.img where they use the same sepolicy?

BTW, I have not been able to get the corrupted data partition again with any of the previous modifications but I am ready to do a diff on those filesystems and partitions when the time comes.

---------- Post added at 10:17 PM ---------- Previous post was at 09:27 PM ----------

I see this may be were things are going for phhusson based on the following commits:

https://github.com/phhusson/Superuser/commit/a021fcf3b6ddda75a13eeb39eee54c727d157f55

https://github.com/phhusson/Superuser/commit/f4622e71abe83e19010e8a2850ac84059583042b

doitright, will this deprecate your patch?
[Nexus 6  General] phhusson:
I don't plan on having source policy on my side, though I expect to have binary tools on par with doitright's patch, and then have tools to check it's the same policy.
[Nexus 6  General] doitright:
You can't read from the data partition until *after* it is mounted.

Not yet, no. Overall, my policy should be more mature than his is yet. There is one change that he implemented that I haven't yet had a chance to pull in, which is the su-daemon context for the su daemon process to run under. This context's only purpose is to transition to other su contexts as needed.

No, LOL, this doesn't deprecate my patch at all!

That second one you linked to actually works *in conjunction with* my patch. Its purpose is to actually build the su binary and Superuser.apk files. You still need a compatible selinux policy and various other adjustments to go along with it. Basically, if you look at the part of my instructions (and patch) that says to build the su binary and copy it into the device path for inclusion, what this change allows you to do is sync the source into platform/external/superuser and have the su binary and Superuser.apk built as part of the boot/system build process.

Instead of adding "device/moto/shamu/su:root/sbin/su" to the PRODUCT_COPY_FILES variable, you would add "su" to PRODUCT_PACKAGES.

You see, the objective is to have two separate way to get this onto a device; as part of the system build (my patch), and as an add-on to a different (likely OEM) system build.

phhusson even has an issue on his tracker related to synchronization between the two approaches.

My patch serves two purposes;

1) as a pattern used during implementation of the binary policy patch,

2) as a means of applying it to a system that is built from source.
[Nexus 6  General] nicholseric:
I put it in post-fs-data. Does that not mean that data is mounted?
[T-Mobile Samsung Galaxy S6] Aqua1ung:
Guys, what would be the latest TWRP for our SM-G920T, and where would I find an Odin-flashable TWRP file? (Somehow I do not trust TWRP Manager with the task of flashing TWRP.)

Just in case it matters, I am currently rooted on the latest DOI1 FW.
[T-Mobile Samsung Galaxy S6] datdirtyscrew:
https://dl.twrp.me/zeroflte/
[T-Mobile Samsung Galaxy S6] Aqua1ung:
Thank you! One of the things that I find irritating about TWRP Manager is that it asks me to confirm/verify the partition where TWRP gets flashed to. Now how can I possibly know if dev/block/platform/15570000.ufs/by-name/RECOVERY is the right place for my device? (Is it?) The second thing that bothers me about TWRP Manager is that it doesn't correctly detect the latest TWRP version, and often it offers to install an older version.
[T-Mobile Samsung Galaxy S6] RiskPrime:
Did twrp-2.8.7.2-zeroflte.img.tar work for you?

After updating to DOI1, I get boot loops after trying to flash TWRP.

I can get into recovery and download mode just fine, but it won't boot to the OS.
[T-Mobile Samsung Galaxy S6] Aqua1ung:
I bit the bullet eventually (sesing as flashing TWRP via ODIN is a PITA), and flashed TWRP using TWRP Manager. I got an error message upon flashing, though it looks like TWRP flashed just fine. (Go figure!) Anyway, TWRP Manager flashes TWRP 2.8.7.1. It may be that TWRP people didn't consider TWRP 2.8.7.2 safe enough to flash, which is why TWRP Manager doesn't offer the option. That may be your explanation for your troubles.
[Nexus 4 Q&A, Help & Troubleshooting] imrock0:
I flashed Frank N4 ROM and my device has been crashing since then. It freezes randomly, becomes totally unresponsive for 5-10 seconds, then reboots. And even when not in use, the device keeps on crashing and rebooting randomly.

I have tried both BaNks as well as Txuki Gapps. Same issue persists.

I have reflashed stock rom, flashed latest twrp, wiped everything except Internal Storage, flashed rom and gapps, wipe cache and dalvik. Done this like 3-4 times. Still no luck.

Any help would be greatly appreciated.
[Nexus 4 Q&A, Help & Troubleshooting] elonus:
Have you tried another ROM, to see if the issue is there as well? If not I would suggest that.
[Nexus 4 Q&A, Help & Troubleshooting] imrock0:
Thanks for your reply!

This was my first Marshmallow ROM. I used to be on Paranoid Android(the latest stable one) and before that on stock rooted 5.1.1. Never had this kind of issue before.

I'll try another Marshmallow ROM and report back.

EDIT: I tried another Marshmallow ROM. I'm experiencing the same issue. I guess all Marshmallow ROMs will make my phone crash. Any help?