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
>> 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.
--
Darren J Moffat
