Shared publicly  - 
 
Some specifics about the 4.3 SuperSU (ramblings)

All this information is subject to change without notice. The current SuperSU at time of writing is v1.45.

Apart from a lot of text, this post also includes stuff a dev would want to know regarding daemon startup and mount namespaces.

Pre-cursor

I was surprised by the large number of negative (sometimes even flaming) responses from even techies that SuperSU didn't magically work perfectly out of the box at 4.3 release. I would like to point out that this daemon version of SuperSU was pretty much just an experiment for the SGS4's 4.3 leak. We didn't know if the new measures were Samsung or Google, or if they would be present in any retail firmwares at all. Samsung tends to protect their engineering firmwares better than their retails. As such, there was a big question if the effort was a pure waste of time or not, and I choose not to continue with it until we had some further certainty.

Yes, then the Nexus 4 firmware leaked, I didn't have time to look at it yet, and I don't even have a Nexus 4. Some have slammed me for not fixing the CPU load issue sooner - I wasn't even aware it was a serious problem until the day before the official 4.3 hit ...

Android 4.3 - it isn't just 4.2 with sweetener

Right now, I'm getting a lot of feedback from a lot of users regarding their favorite apps not working and how it's all SuperSU's fault, the device isn't properly rooted, etc. Stop that.

Android 4.3 is a different beast than 4.2, and on stock-ish firmwares it seems this method of root is here to stay. App developers will have to do their share of updating. Things will not be 100% the same as they were. I aim to make it as similar as reasonably possible, but that alone will not be enough.

If you're a developer, by all means let me know if something is working differently than you expected and if there might be a problem somewhere. You might be right, and it might need fixing. If you're an end-user, you might want to think long and hard whether or not it is something you really want to bother me with, something you want to bother the app's dev with, or something that in all likelihood the app's dev will already currently be looking at (like 4.3 compatibility). The dust will settle soon enough.

hacks, solutions, and updates

Some of the things done for this version of SuperSU may not be ideal, rough-around-the-edges, "hackery", etc. Again, it was partly just an experiment that is only now getting serious. As far as I can see, there is no other way to do this on rooted stock, but if one is found, I will certainly look at that as well.

There's quite a bit of new code involved - there will be bugs, quirks, and updates. We've already had a few of those and there will probably be at least one more very soon.

I am going on vacation this week, and I'll be gone for a while. So development will be stagnant on my end, I hope to leave you with something that somewhat works, even if it isn't perfect.

install-recovery.sh and init.d

At the moment install-recovery.sh is used by the SuperSU installers (app itself, ZIP, CF-Auto-Root, etc) as method to launch SuperSU's daemon at boot. This is not an ideal situation. However, for the time being it seems to be the most broadly available method to do this - and due to vacation I can't dedicate too much time at this specific quirk right now.

As some other apps also use that, I call install-recovery-2.sh after starting the daemon, should anybody need that (for now).

Some custom firmwares and kernels block this and for example use init.d instead. I do plan to support that officially, but until that time it should be trivial for anyone to mod the installer ZIP or actually include SuperSU in that custom firmware itself.

I've been thinking about making init.d support available through install-recovery.sh (if not already available) and launching the daemon through there. Not sure if that's the route I'm going to take, but it's an idea.

If you're making your own firmware and including SuperSU, you can also add a service for daemonsu in init.rc.

EDIT: Note that different ways of running at root, like hijacking a lib by preload through /vendor has also been considered, but was ultimately ruled out as not being very portable.

EDIT#2: install-recovery.sh is also used by OTA updates, you are for the time being recommend to use the "full unroot" option in SuperSU prior to doing an OTA.

mount namespaces

These aren't anything new, Linux has had them for a while, and Android has had them since 4.2. There were already some repercussions to this on 4.2, such as one app remounting system r/w not being visible from other apps, or the same thing with USB sticks and whatnot. Yes, this is how nosuid is done as well (as if anyone was surprised).

Now that SuperSU is running in daemon mode, this means that all your su requests actually get executed in a different part of the process tree that does not share the same mount namespace as your main Android app's java code, libraries, or non-su'd binaries.

This means changes made in a su shell may not be visible to the normal parts of your app. This is also means the su shell does not have your private things mounted - the current user's internal storage, obb's, etc.

The current version of SuperSU does symlink /storage/emulated/<uid> to /data/media/<uid> but this is not ideal, symlinks do not behave exactly the same as mounts. This will transition to mounts in an upcoming release, which will work better - but I will still not be pre-mounting obb's. Some devs have asked me what I meant with that link being marked "temporary" in the SuperSU changelogs. It means just this - I will change the method to mounts. The path itself will remain available.

The proxied su requests currently all live in the same mount namespace. That means that if one app remounts system r/w through su, all other su shells will also have a r/w system (unlike 4.2). As such, root apps can potentially interfere with eachother (as with 4.1 and earlier).

I'm not sure what I'm going to do with that. I am considering making a private mount namespace for each different app, but that will have it's own quirks, cause a little bit of overhead and it'll take some time to build and test.

Anyway, for the time being, if you're an app dev, you should really take care to check what you're doing in with file paths, mounts, etc on 4.3, things may not behave as you initially expect. And to make matters worse, it'll likely be subject to change as well.

Conclusion

This is not perfect yet. It will be a while before it is. Some things will need adjusting on my side, some things will need adjusting on root app dev's side. You can be sure there will be some changes to how some things are implemented for SuperSU on 4.3, but I'm not sure yet exactly what, how, or when.
247
25
Ryan Lu's profile photoHosam Arnous's profile photoreno lara rere's profile photoAndy Xiong's profile photo
31 comments
 
If only Mobile Odin would come to Nexus 7 , the world would be a better place...
 
Enjoy your vacation bro, Ever since my first Android phone you have not ceased to have the fix for everything, Great job! 
 
I've not had a problem with root on stock 4.3 with versions 1.41-1.45

I don't understand a lot of the issues people had - I didn't even have any CPU spikes that was mentioned.

1.41 - only root explorer & titanium backup had issues on mine.

1.43 - it fixed root explorer

1.45 - no noticeable difference to me.

Either way - we'd all be lost without +Chainfire - he's been providing my root since my first android on eclair - Samsung Galaxy S.

As it stands right now, root seems to be working as it should to me. I notice no difference from 4.2 jelly bean. 
Zach M
+
3
4
3
 
Enjoy your vacation. Thanks for all of your hard work. 
 
As said by some, Thanks & Enjoy.
Agent S
 
Agreed, if you're going to complain and whine about problems with a brand new firmware then you should just stick with what you have and update a few weeks or months down the line. If you have something intelligent to report then do it the right way.
Jason W.
+
1
0
1
0
 
+Chainfire has been THE MAN ever since my old school WM5 days... If you want to bitch at him for a FREE UTILITY, you can go jump off a cliff.

Don't let the tards criticizing you get under your skin, CF. Believe it or not, there are tons of people out there that genuinely appreciate the work you do for us.

Keep up the awesome work!
 
...I bought the pro version after installing 4.3 the other day. Now I'm glad I did. Thanks, and enjoy your vacation :)
 
Enjoy your time off and ignore the complaints for a while!
There'll always be haters. Just ignore them. Even if they purchased the product 5 versions ago, that doesn't entitle them to act like you are in debt towards them: they already used the software they paid for, and they should be thankful that you still continue to update it.
 
Good work! I appreciate everything you do. I keep trying tell people that apps need to be updated and not just for root. People may not see a big change but if they take time to read, understand, and have patience. 
 
I have just recently rooted my phone and still not comfortable enough to install a rom but i learn something new every day and a big part of what i do learn is from you and your apps... Thanks so much for your time ...may you have a most blessed vacation and come back refreshed and ready to set the TECH CHAIN ON FIRE.
 
Thanks for your hard work. I have faith in you! 
 
awesome work, man. I'm gonna hold off until the factory images are released, hopefully Monday.
 
Ewwwwwwww!!!!!!!! I hate to say this, but this is starting to look and feel an awful lot like Window$. It's not so unlike the RunAs or SudoWin services. Those may superficially appear to be running with the same context as the logged in user, but in actuality all they have is the "interact with the desktop" right. So similar to the Linux per-process mounts, the processes spawned from the service inherit THE SERVICE'S drive mappings, UNC paths, etc., NOT the ones of the logged in user. In the MS case, it's due to not having any equivalent to suid/sgid bit mechanisms, so instead a privileged service runs/spawns programs on behalf of a client exec'ed in the desktop context.
 
Something to think about with root, how many of the things we use root for could be fixed by 

a) more APIs (and UIs) in Android ( eg. 4.0's VPNService means that OpenVPN no longer needs root, 4.3's App Ops UI means no need for root apps like Permissions Denied )

b) fewer restrictions on existing Android APIs (if Device Administrators could do more things, the Secure Settings would not need root and a system helper to get its work done)

c) unlocked bootloaders (a lot of debloating could be done in recovery, if the bootloader is unlocked)

... and how many of us really need to mess around in the guts of the phone (either because we want to personally, or because the app is doing things that the manufacturer does not want to happen like TriangleAway or BootUnlocker).

See discussions here:
https://plus.google.com/u/0/100275307499530023476/posts/BDVgeKMWaf4
and here
https://plus.google.com/u/0/100275307499530023476/posts/SHyNpFuyo1E
 
Just one other thing about Chainfire: BUY his stuff, don't whine about the free versions. His work has opened up many Android devices whose manufacturers lost sight of the Open Source Project aims and objectives to have a an OS whose Source code belongs to EVERYONE! - rant over. 
 
Thanks for all your work and enjoy your vacation, 4.3 can wait
 
I too had problems getting root, but not once did I ever think to criticize your fine work. Sites that were only one or two days old were citing v1.41 would get me root access, not even knowing that you were already beyond that. V1.45 works for me, and I thank you for your fast and fine work.
I think the Android community as a whole should thank you. How long do we wait for news of JB 4.3, to ACTUAL release to the public? You've done your fixes in days!
Thank you, sir!
 
Just leaving it here, +Chainfire. After flashing the 4.3 factory image on my N4, I installed the SuperSU v1.43 via Zip Installer. Then I updated to v1.44 and v1.45 via Play Store. Now, after both updates, I was left with 2 apks - one in /system (chowned root.root) and one in /data (chowned system.system). See: http://i.imgur.com/Y4cRv1d.png

Have a great vacation! BR

EDIT: Nevertheless, I had no root issues so far! (Actually just spotted that incidentally.)