child DS of an encrypted Dataset - is it encrypted?

[SMnasMAN]

Im aware the answer to my question/topic is YES , IF the child dataset has "inherit (encrypted)" set to YES (ie checked off).

but my question / case is different. Im using pull-replication, and the pull-replication task is the one creating this dataset (and i dont see an option to set THAT DS to "inherit (encrypted)"=YES).

So my question is: is the dataset in this example "public8TBz2-pull" in fact encrypted? Meaning if i were to pull the physical drives from this machine, insert them into a new blank ZFS system, would one be able to access this data, without my encryption passphrase?


(i can confirm the obvious, if i LOCK the parent data set, ie " he8xZ2-PullReplc-8tbRD0" and then look inside of it, the "public8TBz2-pull" dataset is gone - GOOD)

(ofcourse, once i unlock parent data set, ie " he8xZ2-PullReplc-8tbRD0", the "public8TBz2-pull" dataset re-appears - also GOOD)

- but im wondering if its data on this child dataset is actually encrypted on disk, like any other encrypted zfs dataset, or is the parent DS JUST un-mounted and that is why lock hides, the child dataset.

see picts below please,

(why am i not just setting the Encryption setting , in the Replication task for the Destination dataset? BC ive used that setup before, and i end up with many datasets for each of my replication tasks that i have to unlock, anytime the system reboots or has a power issue- so my goal was to just have 1 or 2x parent datasets that i would need to unlock, in cases of reboots on this backup system).

 

[sretalla]

- but im wondering if its data on this child dataset is actually encrypted on disk, like any other encrypted zfs dataset, or is the parent DS JUST un-mounted and that is why lock hides, the child dataset.

If it's set to inherit encryption from the parent (which is the default), then it will be, just using the key of the parent and can't be separately unlocked.

All datasets can be seen (with zfs commands... although possibly not mounted) regardless of encryption, it's just the contents that are encrypted and obfuscated when locked.

 

[SMnasMAN]

If it's set to inherit encryption from the parent (which is the default), then it will be, just using the key of the parent and can't be separately unlocked.

All datasets can be seen (with zfs commands... although possibly not mounted) regardless of encryption, it's just the contents that are encrypted and obfuscated when locked.

thanks for the reply @sretalla - however i do NOT have inherit encryption enabled on this child dataset (but its PARENT dataset does have encryption enabled).

I show the output of the `zfs get encryption` command in my photo above (it shows property encryption = off), which says that the data is not encrypted (it seems).

However im still not clear on how someone would be able to access (mount) an un-encrypted CHILD dataset, of a encrypted Parent-Dataset.
( for example- lets say someone stole my disks, and was trying to connect them to a new ZFS system, to extract the data)

can you shed any light on my above question / scenario?
thanks

 

[SMnasMAN]

I found this line, and it better explains what i think (hope?) is occurring:

This is correct, the encryption property is inherited from the parent unless created without that option. However, I believe that it's unencrypted from the perspective of the parent, if the parent is not unlocked, it's children are not plain text

^ is from this reddit post with the same question as myself (reddit link here)

(this may be wrong / incorrect, but that is what im looking for guidance / confirmation on, hopefully)

 

[sretalla]

The metadata is not encrypted at all in the pool and unencrypted children can be set to mount in a different path than the parent, so there's no reason to feel like an unencrypted child of an encrypted parent is somehow protected from disclosure by someone who knows what they are doing.

Obviously a regular user isn't going to be able to access zfs commands at the server console to do anything like that, so you could assume that it's at least partially "protected".

 

[sretalla]

I note a fix just delivered in U5 fixes a bug not allowing unencrypted datasets syncing when children of encrypted ones... not sure if that helps anything, but worth a mention.

/core/gettingstarted/corereleasenotes/