SU for Android on ChromeOS

[timmypbass]

It's been a while but I believe I used just one script.

 

[maxwintrobe]

... /system/etc/ works for Android, (once the container's been made R/W). Mine's symlinked (via Adaway) to /data/data to save space.

Incidentally, I noticed that /data/data is accessible in Chrome OS at /home/root/*/android-data/data/data and a couple of other locations under /opt and /run (the latter being temporary).

I executed the combined RootandSEpatch.sh script and appear to have successfully acquired root on a Samsung Chromebook Plus, but my /system/etc/ folder is still not R/W for Adaway, is there another step to make this container R/W?

 

[dew912]

I executed the combined RootandSEpatch.sh script and appear to have successfully acquired root on a Samsung Chromebook Plus, but my /system/etc/ folder is still not R/W for Adaway, is there another step to make this container R/W?

Same problem. Can't get write access to /system with Adaway or root explorer. Apps are able to gain root privilege but can't write to the system partition

 

[Nolirum]

I executed the combined RootandSEpatch.sh script and appear to have successfully acquired root on a Samsung Chromebook Plus, but my /system/etc/ folder is still not R/W for Adaway, is there another step to make this container R/W?

Same problem. Can't get write access to /system with Adaway or root explorer. Apps are able to gain root privilege but can't write to the system partition

Which Chrome OS version?

I think it's most likely an issue with /opt/google/containers/android/config.json.

Config.json is the container config, which, along with certain other parts of the OS, has been changed significantly in recent OS versions/updates. There was an issue in the CrOS code which arose fairly recently (in CrOS v65), which rendered it temporarily impossible to mount the container R/W. The underlying issue was apparently fixed in the source code a while back, but the correct container config is quite finicky to get right, and rather easy to get wrong. Since this (writeable Android /system) is an issue that only impacts tinkerers/developers, I imagine that it's not particularly high on the list of things that have to be working correctly when an OS update ships.

Someone raised an issue on the rooting scripts' github last month and, at that time, while there wasn't a particularly straightforward workaround/fix for CrOS v65, for v66 the fix involved removing one line from config.json, and, according to my testing, the issue was not occurring on v67 at that time.

I am currently running v69 and do not experience the issue (i.e. I can write to /system, and the "mount command executed within an Android terminal shows that /dev/loop1 is mounted rw).

If you are running CrOS v66, the fix should be quite simple, and, as I mentioned, on v69 at least, it appears to be no longer necessary. If you are running CrOS v67 or 68, you can try the fix which I previously tested on v66. At some point I may have time to check out v67/68 to confirm this works, but in any case as long as you make a back up of the file, you should have nothing to lose by trying it.

The likely fix: Check my post on github for a little more detail if you like, but, essentially, if you open /opt/google/containers/android/config.json in vi, and see the line:

  "dev",

under the mount options for the Android "/" (it was at line 32 on my device, but this may vary depending on CrOS version), you can remove this line, then reboot, and then the container should mount R/W.

Or, if you want, you can add your config.json (or the first 40 or so lines of it) to a post here, and we can take a look at it to further investigate.

 

[dew912]

Which Chrome OS version?

The likely fix: Check my post on github for a little more detail if you like, but, essentially, if you open /opt/google/containers/android/config.json in vi, and see the line:

  "dev",

under the mount options for the Android "/" (it was at line 32 on my device, but this may vary depending on CrOS version), you can remove this line, then reboot, and then the container should mount R/W.

Or, if you want, you can add your config.json (or the first 40 or so lines of it) to a post here, and we can take a look at it to further investigate.

Good morning and thanks for the quick response. I am on 68.0.3440.25 dev channel on the samsung chromebook plus. I found a similar line and it reads as follows:

"root": {
"path": "rootfs/root"
},
"hostname": "android",
"mounts": [
{
"destination": "/",
"type": "bind",
"source": "rootfs/root",
"options": [
"rslave",
"suid",
"exec"
],
"performInIntermediateNamespace": true
},
{

As you can see "dev" is not present.

 

[Nolirum]

Good morning and thanks for the quick response. I am on 68.0.3440.25 dev channel on the samsung chromebook plus. I found a similar line and it reads as follows:

"root": {
"path": "rootfs/root"
},
"hostname": "android",
"mounts": [
{
"destination": "/",
"type": "bind",
"source": "rootfs/root",
"options": [
"rslave",
"suid",
"exec"
],
"performInIntermediateNamespace": true
},
{

As you can see "dev" is not present.

OK yeah, that's strange. Yes, the config.json snippet you provide appears to be correct for a working R/W mount.

I've just switched my C100 from v69 canary to v68.0.3440.25 dev on one of its CrOS partitions without powerwashing (by changing channel and then deleting the file created in /mnt/stateful/ by the update engine, so it doesn't trigger a powerwash).

Ad-away writing to /system, and writing to /system via Terminal Emulator definitely both work fine for me on v68.0.3440.25 at the moment.

Due to the way I've manually gone over to v68 to briefly test this, I have my user profile and everything on /mnt/stateful (partition 1) carried over from v69 (which CrOS nags about at boot, but it still works) - I'm fairly sure that config.json and most of the other related container config bits and pieces are all just on the rootfs partition (and not, e.g. bind mounted from elsewhere), so I don't think it should make a difference that I haven't powerwashed.

However, to completely rule out being able to replicate this issue I guess I might need to do a complete wipe and start totally afresh. I can probably do that at some point (after backing a few things up), but hopefully that won't be necessary.

Can you have a look to see if /dev/loop1 is mounted ro or rw within the Android container?
If you do, in a Chrome OS root shell:

printf "mount | grep loop1" | android-sh

or in an Android terminal emulator

mount | grep loop1

Does it show as rw?

 

[dew912]

Can you have a look to see if /dev/loop1 is mounted ro or rw within the Android container?
If you do, in a Chrome OS root shell:

printf "mount | grep loop1" | android-sh

or in an Android terminal emulator

mount | grep loop1

Does it show as rw?[/QUOTE]

Good morning, thank you again for the quick response. No, it shows as RO

kevin_cheets:/ $ mount | grep loop1
/dev/loop1 on / type ext4 (ro,seclabel,nodev,relatime,block_validity,delalloc,barrier,user_xattr,acl)

 

[Nolirum]

Good morning, thank you again for the quick response. No, it shows as RO

Yeah, so although the line I mentioned is not present in your config.json, I'm guessing that it may be something similar, still. I had a brief look at some of the changelogs on chromium.googlesource.com related to arc++ and couldn't immediately see anything that might have caused it this time around. If necessary I'll have a proper look again when I have time, later in the week.

I'll set up a completely fresh CrOS install, probably tomorrow, and see if I can replicate the issue.

 

[dew912]

Yeah, so although the line I mentioned is not present in your config.json, I'm guessing that it may be something similar, still. I had a brief look at some of the changelogs on chromium.googlesource.com related to arc++ and couldn't immediately see anything that might have caused it this time around. If necessary I'll have a proper look again when I have time, later in the week.

I'll set up a completely fresh CrOS install, probably tomorrow, and see if I can replicate the issue.

@Nolirum, are you using a Chromebook plus? If not, I would be glad to help if you would like me to test anything. If you are interested PM me for my hangouts info. Thank you again

 

[dew912]

Yeah, so although the line I mentioned is not present in your config.json, I'm guessing that it may be something similar, still. I had a brief look at some of the changelogs on chromium.googlesource.com related to arc++ and couldn't immediately see anything that might have caused it this time around. If necessary I'll have a proper look again when I have time, later in the week.

I'll set up a completely fresh CrOS install, probably tomorrow, and see if I can replicate the issue.

Any update here?

EDIT: No change in dev version 69

 

[Nolirum]

Any update here?

EDIT: No change in dev version 69

Apologies for the delayed response. I've been a bit busy, besides couldn't replicate it my end on any of the CrOS versions or find anything in the source, and I think it can be quite tricky to troubleshoot these types of issue remotely.

however, I can now replicate this issue on v69.0.3491.0 on my device, and after some diffing and A/B testing I have found that this time the source of the problem appears to be within the container. A recent change to init.rc seems to be the culprit.

Starting from arc version 4892840 (on my device), the argument "nodev" has been added to the mount options for the rootfs. On my device this is at line 288 of init.rc.

After removing "nodev" and rebooting, the Android container now mounts read/write again.

i.e.

Edit /opt/google/containers/android/rootfs/root/init.rc

Remove "nodev" from the mount options for the rootfs therein (line 288 on my device).

So the following

on post-fs
    start logd
    # Once everything is setup, no need to modify /.
    # The bind+remount combination allows this to work in containers.
    mount rootfs rootfs / remount bind ro nodev

becomes

on post-fs
    start logd
    # Once everything is setup, no need to modify /.
    # The bind+remount combination allows this to work in containers.
    mount rootfs rootfs / remount bind ro

After a reboot, the Android rootfs is now writeable again.

localhost / # printf "mount | grep loop1" | android-sh 
/dev/loop1 on / type ext4 (rw,seclabel,nodev,relatime)

Edit: I guess you could do it with sed, something like

 sed -i.old 's|mount rootfs rootfs / remount bind ro.*$|mount rootfs rootfs / remount bind ro|g' /opt/google/containers/android/rootfs/root/init.rc

Hopefully the above works for you. If needed I could add this to the rooting script, but it'll probably be best to wait a bit anyway, and see there are any further changes in forthcoming CrOS updates (v70?).

Edit 2: I've had a commentfrom someone else with a Chromebook Plus, and the above fix did not work for them.

I have also found that, on my device, it is also possible to get the Android rootfs to mount RW again by actually changing, on the same line, the RO argument (which, I understand, previously would be overridden by Chrome OS) to RW.

After making either one, or both, of those changes, I found that the rootfs would mount R/W on my device.

So, to change RO to RW, it would be something like

sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc

which should change the line

mount rootfs rootfs / remount bind ro

to

mount rootfs rootfs / remount bind rw

I have suggested that they try this and, after rebooting, check again to see if /dev/loop1 is still read-only in Android.

If/when i find out more on this, I'll post back.

Edit 3. The latter command has now been confirmed to work on the Chromebook Plus on v69 to re-enable the R/W mount for the Android rootfs. It also works for me on v70. I'll probably add it to the rooting script presently.

 

[dew912]

I upgraded to the pro and let the fiancee have my plus. Script works flawlessly on chromebook pro v68 (beta channel) after downloading and extracting su. Thank you for all you do for the community

 

[nabil2000]

No root in SuperSU

I tested your scripts & got it install/patch -

However in SuperSU it says no root detected, & using a root checking app says partially rooted, any idea around this?

Apologies for the delayed response. I've been a bit busy, besides couldn't replicate it my end on any of the CrOS versions or find anything in the source, and I think it can be quite tricky to troubleshoot these types of issue remotely.

however, I can now replicate this issue on v69.0.3491.0 on my device, and after some diffing and A/B testing I have found that this time the source of the problem appears to be within the container. A recent change to init.rc seems to be the culprit.

Starting from arc version 4892840 (on my device), the argument "nodev" has been added to the mount options for the rootfs. On my device this is at line 288 of init.rc.

After removing "nodev" and rebooting, the Android container now mounts read/write again.

i.e.

Edit /opt/google/containers/android/rootfs/root/init.rc

Remove "nodev" from the mount options for the rootfs therein (line 288 on my device).

So the following

on post-fs
    start logd
    # Once everything is setup, no need to modify /.
    # The bind+remount combination allows this to work in containers.
    mount rootfs rootfs / remount bind ro nodev

becomes

on post-fs
    start logd
    # Once everything is setup, no need to modify /.
    # The bind+remount combination allows this to work in containers.
    mount rootfs rootfs / remount bind ro

After a reboot, the Android rootfs is now writeable again.

localhost / # printf "mount | grep loop1" | android-sh 
/dev/loop1 on / type ext4 (rw,seclabel,nodev,relatime)

Edit: I guess you could do it with sed, something like

 sed -i.old 's|mount rootfs rootfs / remount bind ro.*$|mount rootfs rootfs / remount bind ro|g' /opt/google/containers/android/rootfs/root/init.rc

Hopefully the above works for you. If needed I could add this to the rooting script, but it'll probably be best to wait a bit anyway, and see there are any further changes in forthcoming CrOS updates (v70?).

Edit 2: I've had a commentfrom someone else with a Chromebook Plus, and the above fix did not work for them.

I have also found that, on my device, it is also possible to get the Android rootfs to mount RW again by actually changing, on the same line, the RO argument (which, I understand, previously would be overridden by Chrome OS) to RW.

After making either one, or both, of those changes, I found that the rootfs would mount R/W on my device.

So, to change RO to RW, it would be something like

sed -i 's|mount rootfs rootfs / remount bind ro|mount rootfs rootfs / remount bind rw|g' /opt/google/containers/android/rootfs/root/init.rc

which should change the line

mount rootfs rootfs / remount bind ro

to

mount rootfs rootfs / remount bind rw

I have suggested that they try this and, after rebooting, check again to see if /dev/loop1 is still read-only in Android.

If/when i find out more on this, I'll post back.

Edit 3. The latter command has now been confirmed to work on the Chromebook Plus on v69 to re-enable the R/W mount for the Android rootfs. It also works for me on v70. I'll probably add it to the rooting script presently.

 

[nabil2000]

Success root v67 - on hacked Chrome OS ICS Bben cherrytrail with cyan Acer CB R11 ROM

I ran again the script 02SEPatch.sh

curl -Ls https://raw.githubusercontent.com/nolirium/aroc/master/02SEPatch.sh | sudo sh
& it finally gave me root - fiddly, but eventually worked-
I also made the suggested changes to get rw before running it.

Here is the output after the successful run:

chronos@localhost ~/Downloads $ curl -Ls https://raw.githubusercontent.com/nolirium/aroc/master/02SEPatch.sh | sudo sh
Test Rooting scripts for Android on Chrome OS

Version 0.25

Unofficial scripts to copy SuperSU files to an Android system image on Chrome OS

Part 2 of 2

There is an SE Linux policy file located at /etc/selinux/arc/policy/policy.30, which can be patched with SuperSU's patching tool.

This script assists with the process.

Copying policy.30 to /home/chronos/user/Downloads/policy.30 to allow Android access to the file.

Opening an Android shell and attempting to patch policy_30.


supolicy v2.82 (ndk:x86) - Copyright (C) 2014-2017 - Chainfire & CCMT

Patching policy [/var/run/arc/sdcard/default/emulated/0/Download/policy.30] --> [/var/run/arc/sdcard/default/emulated/0/Download/policy.30_out] ...
libsepol.policydb_index_others: security: 1 users, 2 roles, 704 types, 0 bools
libsepol.policydb_index_others: security: 1 sens, 1024 cats
libsepol.policydb_index_others: security: 65 classes, 7695 rules, 0 cond rules
- Success

Overwriting policy.30
Copying patched policy from /home/chronos/user/Downloads/policy.30_out to /etc/selinux/arc/policy/policy.30
Setting SE Linux to 'Permissive' temporarily
Copying Android /sepolicy to /usr/local/Backup/sepolicy.old
Overwriting Android /sepolicy with patched policy.30
Setting permissions and context for /sepolicy
Done!
Please reboot now

Feed -
https://twitter.com/inabster/status/1022893846718492673
https://twitter.com/inabster/status/1019974551751614464
https://twitter.com/meNabster/status/1022789803874689024

I tested your scripts & got it install/patch -

However in SuperSU it says no root detected, & using a root checking app says partially rooted, any idea around this?