Encfs

Security is a thing at my new job. We follow PCI security standards. We take great care never to have our customers sensitive information on unsecured machines. We make efforts to stay aware of the security risks in our environments.

With that in mind, i decide that storing all my work related files on my laptops in clear text was suboptimal. I have thought this same thing at pretty much every job, but i have never done anything about it before.

After a bit of research i settled on EncFS as the best mechanism to encrypt my work related data. It is an encrypted file system. Unlike most of the other encrypted file systems for Linux, EncFS does not require reserving large amounts of disk space up front. EncFS effectively lets you make a directory on an existing file system in which all the files will be encrypted. It is very easy to setup and use.

In addition to normal sorts of files, all my test and development databases need to be encrypted, also. These databases don’t contain any customer data they do contain some information that my employer would prefer not be public knowledge. When the database server starts it cannot access the database files until i provide the encryption password. Fortunately, PostgreSQL is totally bad ass. It will happily start up even if it is unable to access some of the configured table spaces.1 As soon as the encrypted file system is mounted, the databases that reside in the encrypted directory instantly become available. The encryption layer does not even effect performance noticeably.2

One thing i did think is a little weak is that encrypted file systems don’t get unmounted when the computer is put to sleep. No worries. A tiny script in /etc/pm/sleep.d to unmount the file system is all it takes to rectify that situation.

Now if someone steals my laptop the only thing they will be able to access are my family photos. That is a pretty nice feeling. Even better, it turned out to be very easy.


  1. To allow the postgres user to access the encrypted file system you do need to mount it with the --public option.

  2. This is light duty, single user, performance we are talking about. I wouldn’t suggest this setup for a heavy load production environment, but in development it no sweat.

Comments 3

  1. Paul wrote:

    When I had the same problem, I just used LUKS to encrypt my entire /home partition. Not sure why you decided that an expandable directory was important. I considered the same, but I decided it wasn’t really worth the effort. Performance isn’t noticeably slower in this case, either. Did you encrypt your entire /home? If you didn’t, you might have to make sure your chat logs, browser passwords, etc… are all crypted, too. When I realized I didn’t want to worry about all that, encrypting my whole 100GB home partition made more sense.

    Posted 06 Apr 2009 at 12:16 am
  2. Peter Williams wrote:

    Mostly, i wanted the expandability so that i didn’t have to guess ahead of time how much space i am going to need (a la Loop-AES). I choose not to encrypt the whole home partition for various reasons, but most importantly because my home directory lives on a partition that also has /var and a few other things on it. I could repartition my drive, i suppose, but that seem like a pain.

    Which LUKS implementation are you using?

    Posted 06 Apr 2009 at 9:22 am
  3. Dick Brodine wrote:

    I wrote an encryption/decryption tool at Gulf Research and Development for the first time in 1978. Pl/i, Dialog Manager for the full screen interface and a 370 Assembler subroutine from the DOD that handled the encryption. The tool ran on the networked interactive computer that was running the VM/CMS operating system. Nice to see the idea of encryption rediscovered today. There really is nothing new under the sun. Ideas just get repackaged and they resurface to the mainstream once again.

    Posted 07 Apr 2009 at 8:12 am