yashsingh1/xdaforums huggingface dataset:
[Nexus 6  General] doitright:
That one is understandable. Basically, you only need that part of the patch if your distribution has an unsupported version of openjdk (it just tricks the part that validates that you have everything required to build AOSP), in my case, I have 1.8 and AOSP wants 1.7. Making that change allows you to install oracle jdk using their packages, just to satisfy the boot.img build, which doesn't even use jdk.

Known issue when building su+application with eclipse. Change the contents of the packageName file to read "com.koushikdutta.superuser". This will cause a change in the su binary it produces (not the application).

If you can post a dump from dmesg. It should *hopefully* include some logs from verity that might shed some light on what is going on.
[Nexus 6  General] scholbert:
Hi doitright,

just a short and maybe stupid question (it's just to be clear about that ;)):

Is dm-verity activated in the boot.img's you provided?

So in other words, will it be save to mod /system partition or may i run into the warning message then?

Best wishes,

scholbert
[Nexus 6  General] doitright:
It is *NOT* activated in my prebuilt images.
[Nexus 6  General] nicholseric:
Hmm, it is not the package name, at least not yet. I changed it, made image and flashed, same problem. So I thought, what if I use your binary su. Then I compared them. Yours is bigger than mine (lol):

-rw-rw-r-- 1 havealoha havealoha 2624 Oct 28 16:38 spn-conf.xml

-rwxr-xr-x 1 havealoha havealoha 1609648 Oct 29 10:23 su

-rwxr-xr-x 1 havealoha havealoha 315980 Oct 29 10:23 su.me

-rw-rw-r-- 1 havealoha havealoha 3171 Oct 28 16:38 ueventd.shamu.rc

Yours worked without permission denied error. Still get the corrupt device message. At least now I was able to get dmesg. Two things caught my eye:

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

and

[ 9.292348] e2fsck: ext2fs_open2: Bad magic number in super-block

The first one seems to be a problem. The second is because my data partition is encrypted, whew!

Here is the dmesg, maybe you can see what is causing corrupt device message or why verity is otherwise not working as we might expect? https://goo.gl/6vWBYQ

Edit: I was able to su; mount -o bind /data/hosts /system/etc/hosts . So maybe the init.rc needs to be su -c 'mount -o bind /data/hosts /system/etc/hosts' ?
[Nexus 6  General] doitright:
There is some real screwball stuff going on when mounting your /data. Reminds me of someone who had that error, and apparently fixed it by a factory reset, which from everything we know, should *not* work.

Could you backup your data (externally) and try that?

There are NO verity related errors there, only a notice that it was using verity.

I wonder if the reboot-error condition might just be triggered by *any* filesystem corruption error...?

Edit: factory reset via FACTORY recovery, or fastboot format data; fastboot format cache. Factory reset via custom recovery will NOT work.
[Nexus 6  General] nicholseric:
Not worried about my data, I did a flash-all.sh with mra58k then before it rebooted, I flashed my boot.img. Still get the corrupt device spash screen but the log was now happy with my userdata partition. Putting the hosts bind in su -c '' did not work, hosts was just the two liner, but it left no error in dmesg either. Getting nowhere fast with this. I think I'll leave it to the experts and check back in later. Ping me if you need a tester.
[Nexus 6  General] doitright:
Ok, I'll definitely keep you in mind. I do appreciate your help.
[Nexus 6  General] nicholseric:
I ended up getting the corrupt device error even after flashing boot.img back to factory. So I went into recovery and did a Wipe data/factory reset. Now the corrupt device error is gone. I would expect flash-all.sh to accomplish the same thing but I guess not.

Now I am running the boot.img with verity on. There is no corrupt device warning. Android Pay still throws an error when trying to add a card. The mount bind does not work with or without su -c in init.rc but I can run it from terminal emulator. Things can move forward as fast as the dont.

---------- Post added at 11:03 PM ---------- Previous post was at 11:02 PM ----------

My pleasure!
[Nexus 6  General] doitright:
Waitaminute! That is precisely what I said to try :P

Glad to hear that you have verity working now! I thought it would.

Now about android pay, I know that on other devices, like the Nexus 5, it does check for su specifically. There is no verity on Nexus 5, even on Android 6... which means that the key is in figuring out what mechanism(s) it is actually using to detect su, and alter the implementation so that it no longer trips them.

Things such as renaming the su binary to "geoff", or changing the package name throughout.

Since you're obviously advanced enough to handle a bit of implementation, you can take a look at this project I set up here to kill off the monthly security annoyance, and change it instead to run your bind mounts:

https://github.com/lbdroid/StopOTA

What it is, is an on boot receiver. That means that the code runs approximately 5 seconds after the lockscreen shows when the phone boots up. The nice thing about doing it like this, is that you know that by the time the boot is completed, everything is already properly mounted and available. You won't need the second round that sets an alarm or the alarm receiver.

More: You don't need to screw around with the context with this su, that was a hack to deal with the poorly implemented binary su.
[Nexus 6  General] ECrispy:
This is an excellent idea. Some of the technical details are a bit over my head and I need to learn more.

Will this become part of some kernel eventually? Or can it be used with current kernels/roms?
[Nexus 6  General] doitright:
ECrispy: this is independent of the kernel, rather impacting the ramdisk. For a beginner, there may not be much of a distinction between the two, however, since the kernel and ramdisk are packed sequentially into the boot partition. I.e., the "boot.img" contains both.
[Nexus 6  General] nicholseric:
About the waitaminute, I figured that a flash-all.sh would be better and more complete than a factory reset from recovery. Apparently not.

So I thought geoff and I would nail this but no. I went through your patches and changed all /sbin/su to /sbin/geoff plus another occurrence of su or two and I renamed the su binary to geoff. I made the boot image and was able to use terminal emulator to start geoff and superuser asks permission. That part works fine but starting superuser says "The Superuser binary (su) must be updated etc.." That is understandable because I did not recompile the superuser.apk to reference geoff, heck I cant even compile a usable su with ndk-build, mine comes out much small than your binary. So at least geoff starts, asks superuser for permission and gives me root, great. But, android pay still gives the error on trying to add a card.

I would build superuser and su with geoff if I could but Im not getting anywhere with it. I am not using eclipse, my ndk is 10d and I have SDK Platform 23 installed. Do I really need SDK Platform 19 and NDK 9b as https://github.com/phhusson/Superuser suggests? I was just following his instructions on that page but with current sdk and ndk.
[Nexus 6  General] doitright:
Try UNINSTALLING the android application, leave geoff where he is, and rebooting. If then android pay can work, we have an idea that it is detecting the application.

Note that it could be storing the "don't run" state in something. It could require a wipe as well as rebooting.
[Nexus 6  General] nicholseric:
Removing superuser was not enough. I used factory recovery to do a wipe and now android pay works. So I imagine like you that its both the name of superuser package and if it was ever detected, a wipe. So, creating a superuser.apk named something else that references geoff.

I wont touch eclipse and it should not be a requirement to successfully build superuser. This will need some attention. How can I help? Next steps?

What version of ndk and sdk platform are you using? I finally found how to get the 9b ndk https://dl.google.com/android/ndk/android-ndk-r9b-linux-x86_64.tar.bz2

Once I get a working build env for superuser, I see line 49 in su.h is where I might start? Or is that the same as /packageName #define JAVA_PACKAGE_NAME "com.koushikdutta.superuser"

An idea, how about in addition to dynamically fixing up boot.img from custom recovery, su\superuser lays dormant in boot.img and during boot, if the user has a specific file with a private key in it in \sdcard\random or \sdcard\superuser.key, then su\superuser wakes up during init? You get issued the key during the custom recovery modification of boot.img.
[Nexus 6  General] doitright:
Eclipse is *NOT* and *NEVER HAS* been a requirement. Its just what I happen to be using.

Try following the directions in phhusson's readme: https://github.com/phhusson/Superuser

So I presume then that you mean that you still have the geoff binary in place?

Tried rebooting a few times and pay still works?

Then try going back to su binary. pay still works?

Rebooted a few times, pay still works?

Then build the application with a different package name.

As far as the build environment, I can confirm that I am building using the latest api for 6.0. As far as ndk goes, I would have to check the machine I've been using for that, *probably* the latest, but may be older?
[Nexus 6  General] superdragonpt:
Hi

Thanks for this, it's awesome to have a open source su "tool"

I guess most people, still don't understand, how awesome this is/ will be...

cheers
[Nexus 6  General] Shawn5162:
This seams cool http://xdaforums.com/showpost.php?p=63197935&postcount=2. Looks like the same thing but at a bigger scale (because it's Chainfire).
[Nexus 6  General] abuttino:
Hmm. I could have sworn his name wasn't to be mentioned in this thread.

Anyway... To fully implement this, it is best if used in a stock ROM, is this statement correct?
[Nexus 6  General] nicholseric:
I have gone back to boot.img with verity on and your binary named su. superuser is downloaded but not installed yet. I was able to add a card successfully! I added superuser.apk, used su in terminal emulator and then added another card to android pay.

I wonder if the addition of local.prop or /data/hosts and the bind mount is what is tripping safety net?

---------- Post added at 02:03 AM ---------- Previous post was at 01:35 AM ----------

Sure enough, adding local.prop to /data triggers safety net. Not su or superuser.apk.
[Nexus 6  General] ECrispy:
Thanks. What I meant is I see some kernels which list 'selinux permissive' as one of their features which means they'd undo this work.
[Nexus 6  General] nicholseric:
Removing local.prop enabled me to add a card to Android pay. It even works after adding /data/hosts and mount -o bind /data/hosts /system/etc/hosts. So it looks like I can add setprop ro.sf .lcd_density 160 to init.rc

Another idea is to add a recovery private keyed\hashed key\pair file in /sdcard/ for reading properties.
[Nexus 6  General] damodarreddy:
thanks for this doitright ,,, it is high time for change,,,, that too for good:highfive:
[Nexus 6  General] nicholseric:
That idea probably does not sound clear. Here it is better explained. To keep verity and the functionality of local.prop, create a /sdcard/randomname. To secure it, write a custom recovery script that allows you to generate a hash of the /sdcard/randomname . The hash is stored into the boot.img and an init checks the hash before using setprop to parse and set the properties from /sdcard/randomname

And a similar idea for enabling su and superuser.

In addition to dynamically fixing up boot.img from custom recovery, su\superuser lays dormant in boot.img and during boot, if the user has a /sdcard/anotherrandomname file with the value enable su and enable superuser in it, then they get enabled too.

Both these ideas might obfuscate some of the future checks by safety net.
[Nexus 6  General] phhusson:
Erm yes, sorry about that, I changed the build.gradle to be able to make release builds (BTW I'm publishing the APK on https://play.google.com/store/apps/details?id=me.phh.superuser)

I added it in the issue list.
[Nexus 6  General] nicholseric:
Yes, this was the problem.

ndk-build worked fine but after using that su in boot.img (forget what didn't work), I did a ndk-build clean to prepare to modify something. Clean was just left on the screen and I mistakenly copied that portion here. You can see my su binary and its size, is it close to what should be expected?

ls -l ./libs/armeabi/

total 312

-rwxr-xr-x 1 havealoha havealoha 315980 Oct 30 14:51 su

Now that I can build superuser, I'll elaborate on any trouble Monday. Thanks for the pointers!
[Nexus 6  General] TjPhysicist:
Stupid question warning

<warning>

This is a dumb question and I know it. I AM NOT asking this to be a troll, or to incite a war (which i 95% guarantee will happen). I am genuinely asking a question that has bothered me for YEARS and have not been able to answer it myself with any amount of research. PLEASE PLEASE I BEG OF YOU answer in a civil manner, I am honestly asking this question to learn the truth. The last time I asked this question, I got banned from a forum without saying anything more than said question.

</warning>

a very stupid question, but something i've wanted answered for a VERY Long time. I've been using and compiling etc various versions of unix and linux for over a decade now, all of which have a 'root user' or variation thereof (latest versions of solaris' variation of 'root' is arguably different from a traditional user with uid=0). Here's my question, I've been reading up on root on android and all it requires as well as this thread...HOLY CRAP that first post is SO COMPLICATED. SElinux reloading? what? Why in gods name?

So my question is this: Why can root on android not be as simple or almost as simple as root on freebsd or ubuntu? there's a root user, and a su app with setuid. I don't know too much about 'selinux' but ubuntu runs selinux and has no issues with root user being so complex and obfuscated. I am NOT AT ALL pointing fingers here, chainfire is an awesome dev, who does work that i could never do....BUT something somewhere is screwed up if we need to jump through insane hoops of fire and play gymnastics with our code to get something as fundamental as 'root'.

Note: I get that without unlocked bootloader root becomes tough, so for the purpose of simplifying things, let's assume my question is restricted to fully unlocked nexus devices only.
[Nexus 6  General] Official_Noob:
Selling off SuperSU to an unknown entity is like God selling off Heaven to a housing developer.

When Google obtains control of that unknown LLC, the party would be over if it was not for people like doitright.
[Nexus 6  General] androcraze:
It's not complicated. Why do you need ROOT?

On your local Linux or BSD machine, either YOU or someone in-house (your "IT" guy) is the Administrator. That's the way things are set-up.

In the Android eco-system, Google is the Administrator. They've created an OS to protect the users from themselves. All the essential and critical system components are protected behind a solid wall that a normal user can't get at. This isn't bad, and for most users it's truly something that they need. It's a trade-off; users get a static, dumbed-down security model with little to no management required. It's a install-and-leave-it-alone approach that works very well.

You say "as simple as".... Simple for who?

Again, why do you need root? You can install a boot-loader and install things via flashing. I use root for three things: AdAway for blocking ads, a CPU tweaking tool, and my file manager. You can flash a hosts file (MOAAB), the CPU actually works well as-is, and a file manager only needs root if you're peeking on the other side of the curtain; it works fine for data in user-space.

99% of Android (and iOS users) do fine without root privileges; you (and I) are part of that 1% who just can't leave things alone.
[Nexus 6  General] TjPhysicist:
Thanks for answer, actually I root for only one reason: lcd_density change. And yea what you say makes sense.

More to the point, I was looking for a more specific answer, why do we need to "reload selinux"? Wouldn't rooting just be as simple as installing a Rom that has the "missing stuff built back in"?
[Nexus 6  General] androcraze:
There's nothing "missing". Look, Android ***IS***, but yet it ***ISN'T***, Linux. SELinux is working and operational as-is in enforcing mode. You're trying to add something (root) that isn't supposed to be there in the first place. You could build a ROM with these patches and the SuperUser app included and have a fully rooted phone.

[MENTION=6124077]doitright[/MENTION] is providing a solution in two formats (if I'm reading things correctly):

1. For Nexus 5, 6, and 9 devices, you simply install the provided superuser.apk, flash the boot.img, and you should be set.

2. For all other users, he's providing documentation for users and developers to build their own.

In that regard, the "missing" stuff is returned.
[Nexus 6  General] TjPhysicist:
Thanks for the answer so:

1. the complex part of things does mostly come in when you need to do things on non-Nexus devices (which is what I thought as well)?

2. A rom like CM nightly which has root "built in", wouldn't need to do any weird haxor type things then? (like reload or circumvent selinux or exploit something)
[Nexus 6  General] androcraze:
1. For non-Nexus 5, 6, and 9 devices, you (or someone in your device's section on XDA) will have to compile the boot.img.

2. If the CM nightly has root built-in, why install this? Do two roots make a right?
[Nexus 6  General] TjPhysicist:
Not installing this, asking if THAT root does odd things like reload selinux?
[Nexus 6  General] androcraze:
I don't know. I'm not running CM, and I'm not at all familiar with the capabilities of CM's root implementation.

In my mind, root either "works", or it doesn't. By "works", I simply mean: "is root allowing my to add the functionality needed for a given app?"

I'd try CM's root and see; if it does what you need it to do, you can call it good until the next ROM (or until something else breaks).
[Nexus 6  General] superdragonpt:
Exactly.

Sorry OT

cheers
[Nexus 6  General] doitright:
Wow, that is ridiculous. Great to know though, and yeah, it can certainly be worked around. Who the heck would have thought that they would do safety net checks against the data partition?
[Nexus 6  General] doitright:
That is actually an excellent question.

And the answer is strangely simple: the Linux user named 'root' is not regarded special by selinux. In order for any user to do anything under selinux, that user has to be operating in a context that has permission to do that thing.

In a typical desktop Linux, substituting user to root involves transitioning to a very powerful context that can do all the things. In Android, that very powerful context has not been defined at all. So what I have been doing, is defining that context, but in a way where it doesn't quite go too far and allow some application to break everything.
[Nexus 6  General] doitright:
That is silly. Android is as much Linux as Fedora or Ubuntu. And more than that, ALL of this stuff regarding privileged users and selinux is very much universal. A desktop Linux can be configured with a neutered and inaccessible root user just as easily as Android, by doing the exact same things.

I'm not actually doing (1). Yes, I have provided some test binaries, but they really are interim, not intended to be the mechanism for distributing this. Distribution, even for nexus, should ultimately be available via runnable update.zip install method, and will *always* be open source.
[Nexus 6  General] doitright:
You aren't comparing SuperSU to heaven, I hope... More like a brothel. Sure looks appealing, but who the heck knows what kind of damage you will do to yourself if you go in.

Keeping source closed for privileged user access is an incredibly shady thing to do.
[Nexus 6  General] androcraze:
I have no disagreement with the potential to run Linux "neutered"; I've done it on self-booting CDs. I run Fedora and fully understand its foundation for Android.

BTW, thank you for your work on this. When Koush quit updating, I was crushed; I ran his version exclusively through KitKat. I embrace open source, and it pains me when I have to run anything else.

You need a FAQ on the first post; it's mighty detailed for newbies. "I ask you the time, and you tell me how to build a clock!" ;)

And quit being so damn grumpy!
[Nexus 6  General] TjPhysicist:
That answers it perfectly, thank you.
[Nexus 6  General] doitright:
I try not to be grumpy. The intention is to be clear, which maybe comes off as grumpy?

We will get to a more noob friendly iteration, but not yet. I would like to keep it technical while still in such a technical stage of development.
[Nexus 6  General] abuttino:
I completely agree.. Once this is noob friendly, there is going to be a ****storm of questions and this will get in the way.

I've been closely following this thread learning quite a lot. Thanks for the effort.

From the looks of this, it appears to be going into another direction with root that allows our rooted phones not to trip the safety net and keeps verity sane.

Exciting times ahead!
[Nexus 6  General] doitright:
Safety net is not actually a primary concern for the project. It is just coming along for the ride. User confidence in the security of their own system is primary concern, which means keeping verity alive.
[Nexus 6  General] Lost Dog:
Just a quick post for feedback... I'm running this on an encrypted Nexus 6. At the moment I'm only using three apps that need root (AdAway, Cerberus, and Titanium Backup). So far no issues.

I love being able to have a pin for superuser access. Only two issues I've found but both are in the Superuser app and at this point irrelevant to the big picture. The scale of the GUI is off when it's asking for permission (big and overlapping) and if you hit "settings" multiple times it will keep stacking the menu (hit it 5 times, you need to hit back 5 times to get to the main screen).

Fantastic so far!
[Nexus 6  General] nicholseric:
It was probably the trailing \n in the su bin even though it does not error on that. It all builds fine now, the apk and the su bin and it is working in my boot.img with verity on. Rather that implement the changes to the update receiver, I am trying to mount bind my hosts file from init.rc. Can anyone suggest where in init.rc or another init where I can accomplish this? I was able to set lcd density with this on line 357 but the mount bind hosts did not work there.

setprop ro.sf.lcd_density 360

Do I need to use su with a specific context? Do I even need su at all?

Note: If you get this error on NDK 9b, update your NDK, mine worked on 23.0.1:

jni/libselinux/src/fgetfilecon.c:6:23: fatal error: sys/xattr.h: No such file or directory

compilation terminated.

make: *** [obj/local/x86/objs/selinux/src/fgetfilecon.o] Error 1
[Nexus 6  General] doitright:
You have to make sure that the required filesystem/components are ready before you can actually do these things, so for example, you don't want to try bind mounting anything from /data/ until it is actually mounted..

Consider using the "on post-fs-data" section to ensure that /data is mounted.

You can use something like "on property:someproperty=whatever" to trigger code based on a specific property loading, i.e., something within /system/build.prop that lets you know that it has loaded that property, and thus you can continue by loading your own properties.
[Nexus 6  General] Logix:
thoughts on on system-less root? and android pay works with it horray! im sure many users would prefer root done this way esp if it gave another option against chainfire. especially in opensource

http://xdaforums.com/showpost.php?p=63197935&postcount=2