Recently there has been a big fuss about Chromebooks and how the Chrome OS will be folded into android. That is great news for users and even better news for hackers who can get a Linux laptop for as little as $135. Well, almost Linux. It turns out that one needs to jump through quite a few hoops to get to the core of the OS where you can actually use your computer like the baws that you are.
So one of the issues that the the Unix fan will encounter is the strange way local storage is handled. Actually in normal mode there is no obvious and direct way one can affect their filesystem. I will try to provide an introduction to some technical aspects of the Chrome OS while mounting a remote filesystem to your device the traditional way.
Be safe rather than sorry
Before we go on we need to make sure we are safe. Google has implemented a nice way of resetting your Chromebook device to a working state, no matter how hard you have screwed up (almost). To be able to do that you need a USB stick of 4G. In theory you could use 2G but that didn’t work for me. Plug your USB into your Chromebook and go to
Now, if worse comes to worst, plug in your USB, press Esc+Refresh+Power and keep Esc+Refresh down until something happens. For details on how the whole boot process works see the boot flowchart.
Developer mode
The normal mode, that is the default for a Chromebook, is quite restrictive when it comes to hacking your Chromebook. You can do all sorts of stuff like browse Facebook or program arduinos, but no non-cloud stuff. That’s what developer mode is for. Skipping the details of what is going on, in practice the developer mode basically allows you to run a bash shell and also root access.
To boot in developer mode, hit Esc+Refresh+Power and keep Esc+Refresh down. Then hit Ctrl+D and confirm that you want to turn off OS verification. You will be presented with a screen warning you that OS verification is off. Hit Ctrl+Dagain and wait a while for the system to boot. The delay is not your system being slow but rather a security feature.
Black screen of bliss
To most Linux powerusers the mouse is evil and the command line is the normal way of doing stuff. You may be able to get to a tty by typing Ctrl+Alt+Right Arrow (left arrow is actually F1 and right arrow is actually F2) to which you can login as chronos without a password. That didn’t work on my device so I used the graphical terminal emulator that can be fired up with Ctrl+Alt+T. The shell here is called crosh with the command shell to get to a the bash shell you know and love.
A small tour of the filesystem
Poking around the filesystem you will find that the Chrome OS is pretty much like one would expect a Linux system to look like. That is until we check the mounted partitions:
$ sudo mount -l
/dev/dm-0 on / type ext2 (ro,relatime)
[...]
/dev/sda1 on /home type ext4 (rw,nosuid,nodev,noexec,relatime,commit=600,data=ordered)
/dev/mapper/encstateful on /home/chronos type ext4 (rw,nosuid,nodev,noexec,relatime,discard,commit=600,data=ordered)
/dev/sda1 on /usr/local type ext4 (rw,nodev,relatime,commit=600,data=ordered)
[...]
There are tons of interesting stuff to poke around in here but for the scope of this article the following points are:
- The root of the filesystem / is read only.
- You can run no executables from /home
- You can run executables from /usr/local
Also interesting is the usage of each partition:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 1.2G 1.1G 175M 86% /
devtmpfs 938M 0 938M 0% /dev
tmp 939M 8.9M 931M 1% /tmp
run 939M 396K 939M 1% /run
shmfs 939M 16M 924M 2% /dev/shm
/dev/sda1 11G 157M 9.8G 2% /home
/dev/sda8 12M 24K 12M 1% /usr/share/oem
/dev/mapper/encstateful 3.1G 17M 3.1G 1% /var
media 939M 0 939M 0% /media
none 939M 0 939M 0% /sys/fs/cgroup
/home/.shadow/11a9adac1a11571863bc506a4ff71356bcaf7d8a/vault 11G 157M 9.8G 2% /home/chronos/user
You are probably expected to store your data in /home/chronos/user but take my word that Chrome OS swallows up that space before you realize what’s happened. It would be nice to have a network filesystem to work with.
Network filesystems
So let’s see what filesystems we can go for. Let’s first try nfs:
$ sudo mount -t nfs [email protected]:/ ~/public
mount: unknown filesystem type 'nfs'
That’s a shame but I didn’t have my hopes too high for that anyway. nfs is not the cloud and the cool kids only use the cloud it seems. Let’s see what modules the kernel provides.
$ sudo lsmod
[...]
fuse 63981 0
[...]
Bingo! For the uninitiated, fuse is a way to have user-space applications, like archive managers or network protocol implementations, provide filesystem implementations. And that means in our case SSHFS, the way to mount filesystems over SSH. SSH itself is available on Chromebook so there is no reason that this can’t work.
Getting SSHFS
There is no proper package manager for the Chrome OS so we are better off installing SSHFS by hand. I could find no built binaries online so I got it from an archlinux repo:
$ wget http://mirror.rackspace.com/archlinux/community/os/x86_64/sshfs-2.5-1-x86_64.pkg.tar.xz $ tar xvf sshfs-2.5-1-x86_64.pkg.tar.xz
$ sudo mkdir /usr/local/bin
$ sudo cp ./usr/bin/sshfs /usr/local/bin/
$ export PATH=$PATH:/usr/local/bin/
And that is all you need! Now you can just mount your remote partition.
$ mkdir ~/Remote
$ sshfs [email protected]:Users/drninjabatman/Projects $HOME/remote
$ sudo mount -l
[...]
[email protected]:/Users/drninjabatman/Projects on /home/chronos/user/remote type fuse.sshfs (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
And you are in! Read/write and execute access to anything on your remote.
The good, bad and the ugly
The most obvious limitation of this procedure is that you have to mount your network shares manually each time. Since the rest of the system (eg the “Load unpacked extension” dialog) will just ignore your mount you will only be using it with bash. So in ~/.bashrc you can put something like:
if ! sudo mount -l | grep "/Users/drninjabatman/Projects"; then
/usr/local/bin/sshfs [email protected]:Users/drninjabatman/Projects $HOME/remote
fi
And you will probably never know the difference.
Now one cool thing you might actually be able to do is mount a remote share on /nix and then install the nix package manager there, and then the sky is the limit! (and probably Unix sockets playing well with SSHFS)