New Encryption vs Old

[SeaFox]

I recently replaced an older pool with larger disks and added encryption when I made the new pool. I already have a second pool that is encrypted using the legacy GELI method. Today I rebooted the entire system for the first time since getting all the data migrated back.

When the system came back up I had a bit of trouble locating the Unlock command on on the new pool at first. On the older (GELI-encrypted) pool the entire pool shows locked up and I go to the gear menu to unlock it. The newer one doesn't seem to work like that. Even though the entire pool is supposed to be encrypted it still displayed the datasets and child datasets below (???), and the unlock command seemed to be on the main (root) dataset.

I wonder if I did something wrong here. I followed the TrueNAS manual for creating a new pool and chose encryption then, but this kinda acts like I only encrypted a dataset and it doesn't seem as secure to be able to see the names of all the child datasets on the pool before I unlock it. The older pool with the legacy encryption shows nothing until I unlock it.

 

[winnielinnie]

Even though the entire pool is supposed to be encrypted it still displayed the datasets and child datasets below (???), and the unlock command seemed to be on the main (root) dataset.

With native ZFS encryption, "pools" are not encrypted: only datasets are encrypted

Yes, you can encrypt the root dataset (it is a dataset, after all), and you can be granular with your child datasets if you want.

If a child dataset's encryption property is "inherit", then it means it will seamlessly use its parent's encryption properties: unlocking the parent automatically unlocks the child, since they are part of the same "encryptionroot" family.

However, once a new dataset is created, you cannot change whether or not its data is encrypted. The only thing you can change after-the-fact is the keyfile and/or passphrase, as well as iterations, and whether or not you want it to inherit the parent's encryption properties (or to have it become its "own" encryptionroot.)

If you created a non-encrypted child dataset, then you can never "change" it to an encrypted dataset.

EDIT: The TrueNAS GUI is somewhat misleading. It does not allow you to access / unlock child datasets below an encrypted parent (or root) if the parent/root is still locked.

In vanilla ZFS, you can in fact access datasets beneath a locked parent. (But for the sake of TrueNAS, pretend this is not possible.)

 

[SeaFox]

Thanks. That does explain the change in location for the unlock command.

If I understand what you're saying about this parent-child relationship right, I can turn off inheritance and then will be able to set a second password to unlock the child dataset then, but I cannot make the child dataset unencrypted (since the parent is), and I cannot unlock the child without unlocking the parent since one is inside the other.

This still doesn't explain why child datasets are viewable in a situation where the parent is still locked.

 

[winnielinnie]

I cannot unlock the child without unlocking the parent since one is inside the other.

This is a "TrueNAS thing". ZFS itself does not limit this.

You can have an encrypted parent dataset, and a non-inherited encrypted child dataset underneath. Regardless of the parent dataset being locked, you can still unlock and access the child dataset. (Not with TrueNAS, though.) Heck, you can even have an non-encrypted child dataset under an encrypted parent dataset, and still access the child dataset without unlocking the parent first.

But for the sake of TrueNAS: pretend this is not possible

I can turn off inheritance and then will be able to set a second password to unlock the child dataset

If you do this after creating the child dataset, then the dataset will always use encryption. However, yes, you can inherit the parent's encryption properties, or have the child dataset use its own encryption properties. (Keyfile, passphrase, iterations.)

Encryption "on" or "off" is decided when you first create the (child) dataset. (It's permanent.) Inheriting encryption properties (see above) can be enabled/disable any time you want, as many times as you want.

The parent dataset does not dictate whether or not the child dataset will use encryption, let alone whether or not it will inherit the parent's encryption properties (i.e, set the parent as its "encryptionroot"). Yet when you create a new child dataset, by default it inherits the parent's properties. (If the parent is outright non-encrypted, then the child will also be non-encrypted by default. However, you can still create an encrypted child under a non-encrypted parent, and vice-versa.)

This still doesn't explain why child datasets are viewable in a situation where the parent is still locked.

Encryption does not hide ZFS-level structures and metadata.

Even with a root dataset encrypted and locked, you can still view the dataset hierarchy, dataset names, snapshot names, dataset properties, etc, etc, even for all children.

 

[winnielinnie]

This might also help you to visualize the salient points:

Help moving pool to new disks

I have my original GELI encrypted pool, and the disks are getting old and starting to die on me. With the new ZFS encryption, it seems like a good time to both migrate to bigger disks and the new encryption. The new pool is currently in a second TrueNAS server that I spun up temporarily and is...

www.truenas.com

 

[SeaFox]

Okay, so the relationship isn't an "enclosing" one like Matryoshka dolls, it really is more like a family (association, but still separate datasets as far as properties). Plus some of these limitations are just TrueNAS and not ZFS Encryption, and since they can all operate under their own rules this would explain why they all need to be visible separately.

 

[winnielinnie]

Okay, so the relationship isn't an "enclosing" one like Matryoshka dolls, it really is more like a family (association, but still separate datasets as far as properties).

Correct.

(The GUI and layout can be "misleading".)



Try not to think about what pure ZFS can do, and stick to TrueNAS's "rules".

But in a pinch or emergency situation, you can in fact access and/or unlock child datasets that live "underneath" a locked parent dataset, if for some reason you're unable to unlock the parent dataset (because your forgot the passphrase or lost the keyfile.)

As long as the child datasets are not part of the parent's "encryptionroot", they can be independently unlocked and/or accessed. (Not part of the parent's "encryption family" / "encryptionroot". I.e, not inheriting it.)



The only things that are locked/unlocked with ZFS are "encryptionroots". Anything below that is part of the same encryptionroot is seamlessly decrypted as well.

If you have only one "encryptionroot" (let's say the root dataset), and everything else underneath inherits this, then even if you have 9,999 child datasets, you only ever unlock ONE thing: the encryptionroot, which happens to be your root dataset


You can use this command to see which datasets are part of the same encryptionroot:

Code:

zfs list -r -t filesystem -o name,encryptionroot

(Any results that are "blank" are non-encrypted datasets.)