Hacker News new | ask | show | jobs
by pstch 2043 days ago
I find it very unfortunate that file metadata is not encrypted : if you need this to be encrypted, you need to stack LUKS on top of ZFS, and you lose many of the benefits of ZFS (per-dataset encryption, healing ability, RAIDz, etc) while doing so. Running ZFS->LUKS->ZFS to recover some of these benefits is also not feasible at all (ZFS doesn't like to self-host, even through a virtual machine).
6 comments

ZFS encrypts most metadata.

Metadata not encrypted: Dataset / snapshot names, Dataset properties, Pool layout, ZFS Structure, Dedup tables

ZFS encrypts: File data and metadata ,ACLs, names, permissions, attrs Directory listings,, All Zvol data,FUID Mappings ,Master encryption keys ,All of the above in the L2ARC ,All of the above in the ZIL

For most uses and use cases this is net increase in security. You can do some operations on data without needing the keys.

Oh it seems I was mistaken about that. ZFS does encrypt enough metadata indeed. Sorry for the noise.
You don't need to stack ZFS-on-LUKS-on-ZFS, you just need to put ZFS onto LUKS rather than onto the raw disks.

The downside is that you have a choice between encrypting all file data twice, or losing the benefits of ZFS's encryption (mainly the ability to send snapshots to another pool without decrypting them). It would be nice if you could specify a pool key to be used to encrypt all blocks not covered by ZFS native encryption, which would eliminate the need for LUKS.

Yes, and there's another downside to that : it makes me lose the other ZFS benefits (raidz, mirroring, some level of performance).
Use one LUKS volume per raw disk. You'll still get raidz/mirroring.
RAIDZ on LUKS should work similarly to RAIDZ on GELI, no?

Encrypt each hard disk and add the decrypted block devices to the vdev in whatever RAID configuration desired.

What file metadata is unencrypted?
I was mistaken, file metadata is indeed encrypted.
Wouldn't just LUKS->ZFS be enough?
Why does metadata encryption matter?