Darren J Moffat wrote: > Anthony Scarpino wrote: >> Darren J Moffat wrote: >>> Anthony Scarpino wrote (elsewhere): >>>> While writing up the man page.. I thought of a few things that I was >>>> wondering if you considered.. >>>> >>>> Can an encrypted dataset (keytype=dataset) reside in a non-encrypted >>>> (no kek defined) pool? >>> I can see a case for and against allowing this when considering it >>> purely at the feature level as users/admins see things. >>> >>> The admin can control wither users can enable encryption or not by >>> delegating (or not) the "encryption" and "keytype" properties. So >>> there is no need to use the pool wrapping key (ie require the kek to >>> be available) to restrict creation of encrytped datasets. >>> >>> If the admin doesn't want encryption in any dataset delegated to a >>> user then don't delegate those properties and ensure they are >>> inherited as encryption=off. >>> >> Depending on 6647661 (setting pool level dataset properties at >> creation), delegation may be the only control as encryption can't be set >> post-creation. > > I don't see the connection here. encryption defaults to off. 6647661 > means that the top level dataset always has encryption=off but has no > impact on what happens to any other dataset, nor does it have any impact > on setting the delegation of encryption at the top level, ie even with > 6647661 this works: > > # zpool create tank c0d0 > # zfs allow everyone encryption tank > > darren$ zfs create encryption=on tank/darren
Yes, yes.. you're right.. I misread the delegation the first time.. > >>> We need to be able to provide key change for keytype=dataset as well. >>> That means that the actual encryption key for the dataset needs to be >>> done the same way as keytype=pool, ie it is a wrapped key that is >>> stored in the "wrappedkey" property not the actual encryption key. >>> Regardless of the need for key change the encryption key needs to be >>> generated while the dataset is being created; and for the filesystem >>> case it needs to happen before the root directory of the filesystem is >>> created - leaving it unmounted isn't actually enough. >>> >>> So this means that we have an ordering problem for the initial key >>> setup. We need the per dataset wrapping key to wrap the new randomly >>> generated dataset encryption key while we are creating the dataset. >>> That assumes that 'zfs key -l' has been run, but we can't do that >>> because the dataset doesn't exist yet. >>> >>> We also worked out that this could be tricky for the cli, because it >>> seems to imply a three step process that isn't atomic - and this I >>> think is a bad model. >>> >> Why can't we just hold off dataset key generation for keytype=dataset >> until the 'zfs key -l" command? > > Because we need the key to encrypt things that are written to disk > during the dataset creation - specifically the root directory of the > dataset. > So given option 3, you would either add a 'zfs key -l" before "zfs key -c" to set the key first, or "zfs key -c" has to learn it can also do an initial set.. hmm
