Assuming an encrypted dataset can''t be mounted before the required key is available, when should it be mounted ? Should providing the required key (either via ''zpool key -l <pool>'' or ''zfs key -l <dataset>'') automatically mount the dataset ? or should an explicit mount be required ? The current code base requires an explicit mount but I think from a usability view point it should be implicit for the ''zfs key -l <dataset>'' case that the dataset is mounted. For the ''zpool key -l <pool>'' case an implicit ''zfs mount -a'' is done, which would mount any dataset who''s key is now present. Why not mount them but return an error on any attempt to access data ? The primary reason for not mounting them when the key is not present is because an encrypted dataset could contain the mountpoint for another dataset (encrypted or clear). I think this simplifies things - but I need to investigate a little more in this area. -- Darren J Moffat
One of the great features of ZFS is its simplified administrative model. I like that I don''t have to utter a separate mount command. For that reason, I think that the mount should be implicitly perform when ZFS and the encryption software has what it needs. I was actually confused/not happy with the new subcommand ''zfs key'' that introduced a new step in ZFS filesystem creation. I understand that the ZFS folks didn''t want to the encryption feature to interpose a new administrative experience on ''zfs create'' (i.e. asking for a passphrase). That seems reasonable but did anyone investigate a new ''create with encryption'' subcommand where the setup, creation and mount happens atomically? Cindi Darren J Moffat wrote:> Assuming an encrypted dataset can''t be mounted before the required key > is available, when should it be mounted ? > > Should providing the required key (either via ''zpool key -l <pool>'' or > ''zfs key -l <dataset>'') automatically mount the dataset ? or should an > explicit mount be required ? > > The current code base requires an explicit mount but I think from a > usability view point it should be implicit for the ''zfs key -l > <dataset>'' case that the dataset is mounted. For the ''zpool key -l > <pool>'' case an implicit ''zfs mount -a'' is done, which would mount any > dataset who''s key is now present. > > Why not mount them but return an error on any attempt to access data ? > The primary reason for not mounting them when the key is not present is > because an encrypted dataset could contain the mountpoint for another > dataset (encrypted or clear). I think this simplifies things - but I > need to investigate a little more in this area. >
Cynthia McGuire wrote:> One of the great features of ZFS is its simplified administrative model. > I like that I don''t have to utter a separate mount command. For that > reason, I think that the mount should be implicitly perform when ZFS and > the encryption software has what it needs. > > I was actually confused/not happy with the new subcommand ''zfs key'' that > introduced a new step in ZFS filesystem creation. I understand that the > ZFS folks didn''t want to the encryption feature to interpose a new > administrative experience on ''zfs create'' (i.e. asking for a > passphrase). That seems reasonable but did anyone investigate a new > ''create with encryption'' subcommand where the setup, creation and mount > happens atomically?For the case were the wrapping key being used is the pool level one (ie keytype=pool, which is the default) then that is actually what happens. See the other thread I just started for a discussion on how we do key setup (and thus mount) for keytype=dataset. -- Darren J Moffat