Comment 25 for bug 1756840

Another ecryptfs use case that I didn't notice in these comments:

Protecting a directory tree within a user's home directory, to be unlocked for short term use and then re-locked immediately afterward, without logging out or requiring root access. This is appropriate for limiting the exposure of your sensitive files while using software that runs as you (and therefore has access to all your files) but you don't trust to be free of exploits (e.g. web browsers or games).

A common pattern is to exit all programs that don't need access to your encrypted directory, then unlock it and do your viewing/editing, then re-lock it before using complex or proprietary software again. In the physical world, this is like putting your private papers in a locked filing cabinet while guests visit, rather than leaving them on your desk.

LUKS/dm-crypt are not well-suited for this use case, since they require carving out a fixed-size chunk of disk space (which wastes space until it is filled and denies additional storage once it is filled), and since they require root access to set up.

It looks like fscrypt might one day be well-suited for this use case, but it doesn't appear to be ready yet.

That means that Ubuntu does not yet have a good replacement for ecryptfs, which was an officially encouraged tool not very long ago. I hope we'll all keep this in mind before telling people they should not be using it.