editing hosts file on HP Chromebook X2 71.0.3578.27

[mmirg]

HP Chromebook X2
71.0.3578.21
11151.17.0 (Official Build) beta-channel soraka-unibuild (soraka)
Google_Soraka.10431.75.0
ARC Version
5090785

I used to be able to successfully edit the/system/etc/hostsin ARC++ after rooting and have my edits reflected in network usage. As I'm not longer able to write directly to the system, I've modified the script to have a relative link to /data/hosts so that I can continue to write to the file.

ls -l /system/etc/hosts
lrwxrwxrwx 1 u0_a55534 u0_a55534 16 2018-11-02 13:22 /system/etc/hosts -> ../../data/hosts

ls -l /data/hosts
-rw-r--r-- 1 root root 3772970 2018-11-02 22:37 /data/hosts

However, as of updating to 71.0.3578.27, making edits to my hosts file is not reflected in use.

For example, the following hosts file:

127.0.0.1 localhost
::1 localhost

127.0.0.1 untd.com

Is ignored and I get the following:

PING untd.com (64.136.45.220) 56(84) bytes of data.
64 bytes from www.dca.untd.com (64.136.45.220): icmp_seq=1 ttl=239 time=31.2 ms
64 bytes from www.dca.untd.com (64.136.45.220): icmp_seq=2 ttl=239 time=32.5 ms

I'm not sure if this is specifically root related and it could be something else that has changed on the ARC side for networking. I tried editing hosts in Chrome OS and the changes are respected on the Chrome OS side but not in Android.

ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope: Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:0 TX bytes:0

arc0      Link encap:Ethernet  HWaddr de:ad:be:ef:fa:ce
          inet addr:100.115.92.2  Bcast:100.115.92.3  Mask:255.255.255.252
          inet6 addr: fe80::2ff:aaff:fe00:55/64 Scope: Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1862 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1765 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1191488 TX bytes:317975

[nolirium]

So it looks like the rooting script needs updating a bit. Hopefully I'll get that sorted quite soon. In the meantime, I took out my OG Flip (arm) on v72 and just tried the script again on this device for the first time in a little while. I did notice an error from sed near the start, as it couldn't find /etc/init/arc-setup-env.

It turns out that the location on the filesystem of the pair of flags that tell /usr/sbin/arc-setup to set up a writable container mount and to make Android boot with ro.debuggable has been recently changed (again), and, at least in v72, these are now in /usr/share/arc-setup/config.json.

I guess something like the following has to be added to the script now.

if [ -e /usr/share/arc-setup/config.json ]; then
  mkdir -p /usr/local/Backup/arc-setup
  echo "Copying usr/share/arc-setup/config.json to /usr/local/Backup/arc-setup/config.json.old"
  cp -a /usr/share/arc-setup/config.json /usr/local/Backup/arc-setup/config.json.old
  cp -a /usr/share/arc-setup/config.json /usr/share/arc-setup/config.json.old
  echo "Setting '"ANDROID_DEBUGGABLE": true' and '"WRITABLE_MOUNT": true' in /usr/share/arc-setup/config.json"
   sed -i 's/"ANDROID_DEBUGGABLE": false/"ANDROID_DEBUGGABLE": true/g' /usr/share/arc-setup/config.json 2>/dev/null
   sed -i 's/"WRITABLE_MOUNT": false/"WRITABLE_MOUNT": true/g' /usr/share/arc-setup/config.json 2>/dev/null
fi

After running the above in the CrOS shell, rebooting CrOS, and then also changing the 'ro' to 'rw' in init.rc and rebooting Android

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

Everything was then writable as normal. Hopefully that'll be the same for you? (Although I wouldn't be surprised if there may be something different in v71)...

Oh, and regarding the issue with the hosts, not too sure about that - I do remember having trouble with a relative symlink there at some point myself, but I can't recall the specifics now, unfortunately. I think it might have been problematic having a relative symlink that's pointing outside of the container, maybe? It was a while back now and I can't remember now whether I got it working or if I just dropped the attempt in favor of figuring out how to get the system writable again.

[mmirg]

Editing /usr/share/arc-setup/config.json fixes the mounting the ARC rootfs as writeable and everything seems to be working as normal again in v71. I'm perplexed as to the issue I was having with editing the hosts file. It works when the rootfs is writeable but it doesn't work when I have the file symlinked to /data. I can't figure out what mechanism might be causing this.

I haven't been submitting pull requests against the script as I figured that you might want to merge the two branches and get things up to speed in the future. Perhaps it's worth waiting for v73 to hit dev? My understanding is that canary on some devices is running Android Pie in ARC++ and I assume some further tweaks will be needed when that change lands.

As for editing init.rc to mount rootfs as rw, I presume this can be done in the script and applied to /usr/local/Android_Images/Mounted beforehand rather than rebooting and then manually patching init.rc?

[nolirium]

Apologies for the delayed response. I was waiting until after I'd had a proper chance to look into why the symlinked hosts file wasn't working. Unfortunately I haven't been able to figure it out yet either.

Editing /usr/share/arc-setup/config.json fixes the mounting the ARC rootfs as writeable and everything seems to be working as normal again in v71. I'm perplexed as to the issue I was having with editing the hosts file. It works when the rootfs is writeable but it doesn't work when I have the file symlinked to /data. I can't figure out what mechanism might be causing this.

My initial thought was that it could be to do with the ongoing "Hardening against malicious stateful data" efforts, which have lately included much blocking of symlinks etc. on the stateful partition, with some whitelisting.

I'm not too familiar with some of the vagaries of the cryptohome mount flow etc., so am unsure about this at this point. The arc++ container-bundle readme has the following:

Once the user signs in, arc_setup.cc‘s OnBootContinue() function unmounts the read-only /data, and then bind-mounts /home/root/${HASH}/android-data/{data,cache} to /data and /data/cache, respectively. These source directories are writable and in Chrome OS user’s encrypted directory managed by cryptohome.

If the issue were caused by the symlink blocking policy, then per /sbin/cros_startup (source) we should normally be able to manage it by either creating /usr/share/cros/startup/disable_stateful_security_hardening, or maybe just adding the correct file path into the file located at /usr/share/cros/startup/symlink_exceptions/arc-symlink-exceptions.txt

However, those didn't work for me, and I am still unsure about whether this actually is the cause of the issue.

I haven't been submitting pull requests against the script as I figured that you might want to merge the two branches and get things up to speed in the future. Perhaps it's worth waiting for v73 to hit dev? My understanding is that canary on some devices is running Android Pie in ARC++ and I assume some further tweaks will be needed when that change lands.

Yes, I imagine some changes may be needed, and as you suggest, once the dust settles on P, it might be a good time to tidy up the script/merge the branches and such.

In the meantime, if it isn't too much trouble, please feel free to let me know of any major issues or potential improvements though.

As for editing init.rc to mount rootfs as rw, I presume this can be done in the script and applied to /usr/local/Android_Images/Mounted beforehand rather than rebooting and then manually patching init.rc?

Oh yes, sure. I've added this to the script now. I was just intending to emphasise in my comment for anyone else reading at the time, that the config.json fix wouldn't work without also doing the init.rc fix.

[OScommander]

Is there an updated script to address these issues?