linuxencryptionchromebookchrootcrouton-os

Cannot access files within launched crouton but can from within chroot?

I recently updated a chroot on an old Chromebook from Ubuntu bionic to focal. The chroot has encryption enabled.

I usually work with Git repositories and other files within the Chrome's Downloads folder and haven't had any issues with this previously.

Since the update though, I found I was unable to run things like git clone -- I get an error saying cannot create worktree dir: no such file found. I looked around and found people had similar problems but there's been no clear solution.

Then I decided to look inside one of the existing folders within Downloads and noticed a problem there...

  1. I can open a repo within my Downloads folder on ChromeOS and see all files as I used to.
  2. I can enter-chroot and run ls on the same folder and see all files as I used to there too.
  3. But when I launch the chroot/crouton (I used xfce4), and try to ls the folder from within the terminal, or even look at the folder contents from a UI window, the contents of the repo look encrypted -- as in all the filenames have changed to strings of equal-length and apparently random characters.

It's almost as if encryption is working in reverse -- so my files are unencrypted outside the crouton, but as soon as I go into the xfce UI, they're encrypted and there's no decryption happening. But that's speculation on my part...

Any ideas as to what is going on here? And how I can continue to work within crouton?

Solution

  • It seems this is to do with the fact that Chrome OS encrypts files and that something had happened since I updated Crouton (rather than my updating Ubuntu from Bionic to Focal).

    I realised this was a bigger issue when even command line tools like tar and git (which I'd installed) weren't working.

    When I tried to unpack a download of Firefox with tar xjf I got an error saying "Required key not available". Some searching around that led me to issue #3261 on the Crouton Github repo.

    The solution for me was:

    1. Ensure /etc/pam.d/su-l was writable. (I did ls -l /etc/pam.d/su-l to check but ultimately used sudo...)
    2. Edit the file /etc/pam.d/su-l. (I used sudo vi /etc/pam.d/su-l to ensure the file wasn't read-only in that instant, and because I had no other text editor options but vi available.)
    3. Comment out the line session optional pam_keyinit.so force revoke. (So it should read # session optional pam_keyinit.so force revoke.
    4. Save the file.
    5. Restart the chroot.