Yesterday I started playing with ZFS, and I noticed something:

When you create an encrypted dataset, and don’t set up automatic mounting, or mounting fails for some reason, the dataset path will still be on the file system, and you’ll be able to write to it. Worst case, this would write sensitive data by some naive process into the unencrypted directory, leaking sensitive data.

The Solution

Let’s say your zpool is called data, your encrypted dataset is called encrypted, and the mount path is /mnt/data/encrypted.

Make sure that data/encrypted is UNmounted, now simply run (with root rights):

sudo zfs unmount data/encrypted
sudo chmod 0 /mnt/data/encrypted
sudo chattr +i /mnt/data/encrypted

This will remove all permissions (read/write/execute) for that path from any user (except root), and additionally we make it immutable, so that root can’t write to it either.

You can test this with:

echo test | sudo tee /mnt/data/encrypted/test

This should give you a permission error…

But mounting to that path is still possible!

zfs mount data/encrypted

Now that we mounted our encrypted dataset, the permissions of that dataset are the ones that count, and for that we do have rights!

Now, if you run the test command again, it should create that test file.

In simple terms, if it’s mounted (encrypted) we can write, if not, not.

Conclusion

This is a very easy yet effective way to prevent potential leaks of sensitive data.

I run this blog in my free time, if it helped you out, consider donating a coffee. (:

That’s all there is to it!

PS You can follow the same guide for the zpool itself, in our case under /mnt/data!