fscrypt does not work for home directory encryption

[Adar Dembo]

I am trying to use fscrypt in place of ecryptfs to encrypt my home directory, and to automatically unlock/lock it on login and logout. I am using a fresh installation of Ubuntu 18.04 done on 05/01/18. The hardware is a Dell Precision 5520 laptop. The version of the fscrypt and libpam-fscrypt packages is 0.2.2-0ubuntu2.

I began with the instructions in https://github.com/google/fscrypt#setting-up-fscrypt-on-a-directory. I quickly ran into bug #1754270, but after applying the workaround from that bug report I was able to successfully encrypt a directory. With that out of the way, I set up a new encrypted home directory, copied all of my files into it with rsync, then moved it on top of the old home directory.

When I logged out and logged back in, I was presented with a blank screen. The cursor was visible and responded to trackpad motion. If I clicked the top right of the screen, I saw the usual drop-down menu containing power settings and the like. I didn't see any other responses to clicks or keypresses. Hitting ctrl-alt-fn-f1 brought me back to the login screen. If I tried to login again, this time the desktop came up normally and everything appeared to be working.

All of this suggests some sort of broken interaction here between pam_fscrypt.so and the rest of the desktop startup process. There are some open upstream bugs [1][2] about this, but I don't know enough about PAM and systemd to understand what might be at fault.

This is sufficiently inconvenient that I'd consider the "encrypt home directory via fscrypt" workflow to be broken on Ubuntu 18.04 at this time.

1. https://github.com/google/fscrypt/issues/77
2. https://github.com/google/fscrypt/issues/95

[Adar Dembo (adembo)]

I built fscrypt from upstream (v0.2.3-8-g3e32282) and this issue no longer manifests. So whatever bug I'm running into has been fixed upstream.

[Trent Lloyd (lathiat)]

It works for me with my workaround applied, however your groups get messed up on login due to this bug: https://github.com/google/fscrypt/issues/77

I've mostly gotten away with that being broken but it causes weird issues, including problems with snaps as well as anything that needs a group (virt-manager, wireshark, etc). And gnome-terminal is fine as a terminal but other terminals are not because gnome-terminal runs under the system-user session (using gnome-terminal-server) where as most other terminals end up launched under the session context which has the broken groups which means sudo is also broken in that case.

I am however using Xorg because of NVIDIA and not Wayland, I wonder if that may have extra issues. Since your problems are display related.

You'd probably want to check "journalctl --user" as an initial log to start with for clues.

In any case fscrypt is definitely broken out of the box, the groups issue isn't fixed upstream but since your issue is fixed with upstream fscrypt i'm not sure what issue you are running into.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Redsandro (redsandro)]

So we cannot encrypt our home directory the old way in Ubuntu 18.04, and we cannot encrypt home the new (fscrypt) way as adviced in the release notes.

Not everyone agrees that encrypting the entire disk is the best choice. Industrial progress has increased battery life and decreased power usage, but that doesn't mean we can waste these improvements on encrypting all our publicly available software just so our documents can remain private.

fscrypt sounds like a great improvement over fuse ecryptfs; but apparently there are two critical bugs.

I'd consider Ubuntu 18.04 finished when there's a user-friendly GUI/installer option to "encrypt (only) home".

Is there a popularity contest somewhere where my colleagues and I can vote or otherwise help raise awareness for the preference to have fscrypt-type home encryption work from the installer as easily as the old home encryption used to work?

[Adar Dembo (adembo)]

Having used this configuration (with upstream fscrypt) for a week, I'm finding that some logins are successful while others are not. So there's still some underlying intermittent issue

[jeltsch (michael-jeltsch)]

I have been waiting eagerly to migrate my laptop from 16.04 to 18.04. 16.04 is getting old for some of the stuff I am doing. I have a 1TB SSD disk with 800 GB of ecryptfs-encrypted data in my home folder. I wouldn't mind whole disk encryption, but I have at the moment no place where to temporarily store the 800 GB of data to select the full disk encryption. The situation is ridiculous...

[Adar Dembo (adembo)]

Trent Lloyd, did you manage to work around the problem with broken snaps? Asking because it looks like there's an update for the gnome-calculator snap that has broken the calculator on my system. Nothing happens when I run it, and if I run "snap refresh" from the command line, I get the following error:

error: cannot perform the following tasks:
- Copy snap "gnome-calculator" data (cannot copy "/home/adar/snap/gnome-calculator/167" to "/home/adar/snap/gnome-calculator/178": failed to copy all: "'/home/adar/snap/gnome-calculator/167' -> '/home/adar/snap/gnome-calculator/178'\ncp: cannot create directory '/home/adar/snap/gnome-calculator/178/.local': Required key not available\ncp: cannot create directory '/home/adar/snap/gnome-calculator/178/.config': Required key not available\n'/home/adar/snap/gnome-calculator/167/.themes' -> '/home/adar/snap/gnome-calculator/178/.themes'\ncp: cannot create symbolic link '/home/adar/snap/gnome-calculator/178/.themes': Required key not available\n'/home/adar/snap/gnome-calculator/167/.last_revision' -> '/home/adar/snap/gnome-calculator/178/.last_revision'\ncp: cannot create regular file '/home/adar/snap/gnome-calculator/178/.last_revision': Required key not available" (1))

[Adar Dembo (adembo)]

Spoke too soon: the simple workaround is "snap remove gnome-calculator; snap install gnome-calculator".

[Paddy Landau (paddy-landau)]

This bug needs to be assigned a high priority, because right now there is no working encryption method that is considered reliable.
• ecryptfs is considered buggy and insufficiently maintained.
• fscrypt is unusable as described in this bug report.
• Full-system encryption is unsuitable for most users, because it wipes any other OS such as Windows. (There is an alternative — https://goo.gl/KtsLMk — that doesn't do this, but it has two important flaws.)

[Digital Spinner (digital-spinner)]

Bump! This is must-have feature which should be working and re-enabled as an option during the installation! No more Ubuntu for me if this encryption won't be fixed/restored.. It is very useful when you are running headless server somewhere where you do not have access to type the full disk encryption password! You can still encrypt other mounts with LUKS whatever you like anyway.

[Redsandro (redsandro)]

Ubuntu 18.04.1 is released., This issue is not fixed, not addressed, not acknowledged as being an issue by key developers, and no plans to do this in the future were announced.

We have migrated our computers to Linux Mint 19 Tara, which (still) supports ecryptfs home encryption. The one drawback according to the release notes is that in order to work around bugs that were introduced upstream, the encrypted home will _not_ be unmounted when a user logs out.

This is acceptable to us, first because the boot time is blazing fast (under 5 seconds), but second and more importantly, full disk encryption is not acceptable to us for multiple reasons.

[Digital Spinner (digital-spinner)]

Yeah, same here. Migrating to Linux Mint because it is easier, and the home encryption is a must have for me, despite it's drawbacks etc. The Ubuntu shouldn't call the latest 18.04 release as LTS release - I do not understand why the backward compatibility is broken from one LTS release to another..

Still I'm looking into future with more and more Linux on Desktops (Workstations) and servers but there are still some additional issues which needs to be addressed (https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html).

And personally for me there are two functionalities which are missing and are critical for me:
- *PROPER* RDP (Remote Desktop Protocol) replacement with strong connection encryption
- *PROPER* /home directory encryption (which helps protect data), as a workaround it could be even full disk encryption but somehow I need to type the password during boot via SSH to run the PC/SERVER which that is why I prefer home encryption, which additionally won't prevent the server itself from booting and starting up standard services like mysql, web etc..

[Troels Liebe Bentsen (tlbdk)]

I got fscrypt working with home folder encryption on Ubuntu 18.10 with some small fixes, I have created a guide here:

http://tlbdk.github.io/ubuntu/2018/10/22/fscrypt.html

[Bruno (bruno-42)]

I did run into the same issue as @adembo. snap refresh does not work, if the home directory is encrypted (fscrypt).
The snap is lxd (linuxcontainer). snap refresh => ... Required key not available" (1)).
But doing a
snap remove lxd; snap install lxd
is not an option - as this resets the whole lxd installation - ending up without any lxd configuration (no network, no storage pools, no containers ...)

[Redsandro (redsandro)]

The method described by @tlbdk works on Ubuntu 19.04. I'd like to get this working on a series of Ubuntu 18.04.2 LTS machines. But the packages are at 0.2.2 rather than 0.2.4.

[Paride Legovini (paride)]

Is this still an issue with Cosmic and later releases, shipping fscrypt 0.2.4-2?

[Redsandro (redsandro)]

Be advised that it is dangerous to use fscrypt without umask 077, as any user can read the contents of any file you access even if they don't have the security token.

https://github.com/google/fscrypt/issues/132

[Nafallo Bjälevik (nafallo)]

@legovini: I can reproduce this on focal with policy_version:2 (see LP:#1867426).

[Kirill Fertikov (fertkir)]

On 20.04 I I have the issue upgrading Chromium (which is installed from snap package).
The issue looks like @adembo's: permission is denied when upgrading snap. So after an upgrade all my Chromium user settings are reset.
Also I have a "permission denied" problem opening hidden files from Chromium.
I've set up the fscrypt using this guide: http://tlbdk.github.io/ubuntu/2018/10/22/fscrypt.html

[Nafallo Bjälevik (nafallo)]

Actually, I was using policy_version: 1 until I upgraded the fscrypt package to be recent enough to include support for policy_version: 2. Everything I've tried so far works fine with the new policies. That includes refreshing snaps and mounting my home directory into a lxd container.

[Kirill Fertikov (fertkir)]

I also upgraded to the latest fscrypt which supports policy_version 2, and I confirm that snap upgrades work without issues of losing user settings.

But I still have an issue with hidden files. The issue is the following: I'm trying to install a Chromium extension from a folder in my home directory. When the directory isn't hidden, it's being installed successfully. But when I make the directory with extension hidden and try to install it, the Chromium file dialog says: Error opening directory: Permission denied.

[Steve Dodd (anarchetic)]

Note that lightdm in focal seems to have problems with v1 policies too, at least in some cases: https://github.com/google/fscrypt/issues/203 .