zfs crypto discuss - Feb 2008 - Should providing the crypto key mount the datasets ?

Some background for context:

A given encrypted dataset my require either the pool level key 
(keyscope=pool) or a key specific to that dataset (keyscope=dataset).

The commands to provide that key are ''zpool key -l
<pool>'' and ''zfs key
-l <dataset>'' respectively.

When the pool is imported (or the system reboots) the key is not 
automatically loaded and requires an explicit load (as above).  This 
means that encrypted datasets are not automatically mounted at import/boot.

When the key is provided should the encrypted datasets be automatically 
mounted  ?

For keyscope=dataset it would look like this:

$ zfs key -l tank/home/darrenm
$ cd /tank/home/darrenm/

That is an easy case since we know explicitly which dataset you wanted 
mounted so it seems obvious that the mount should be implicit if the key 
load succeeded.

For keyscope=pool there could be many datasets that can now be mounted 
that couldn''t previously:

# zpool key -l tank
# zfs mount -a
$ cd /tank/home/darrenm/

Question:  When we load a pool key should all encrypted datasets with 
keyscope=pool be automatically mounted or should the admin have to 
explicitly mount them by name or by using ''zfs mount -a'' ?



-- 
Darren J Moffat

Hi Darren!

> When the key is provided should the encrypted datasets be automatically
> mounted  ?
[...]
> Question:  When we load a pool key should all encrypted datasets with
> keyscope=pool be automatically mounted or should the admin have to
> explicitly mount them by name or by using ''zfs mount -a''
?
Just my semi-informed opinion from a naive user standpoint:

The ZFS style seems to be to do as much as possible automatically.
When I set share options, the fs is shared.  When I set or update
a mount path, the mount is made or updated.

Hence, I would prefer auto-mounting.  If the admin does not want this,
he should have a way to selectively disable it.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt                  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH              WWW: http://www.bb-c.de/~vab/
Am Wiesenpfad 6, 53340 Meckenheim                     Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgr??e: 45
Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt

Volker A. Brandt wrote:
> Hi Darren!
> 
> 
>> When the key is provided should the encrypted datasets be automatically
>> mounted  ?
> 
> [...]
> 
>> Question:  When we load a pool key should all encrypted datasets with
>> keyscope=pool be automatically mounted or should the admin have to
>> explicitly mount them by name or by using ''zfs mount
-a'' ?
> 
> Just my semi-informed opinion from a naive user standpoint:
> 
> The ZFS style seems to be to do as much as possible automatically.
> When I set share options, the fs is shared.  When I set or update
> a mount path, the mount is made or updated.
> 
> Hence, I would prefer auto-mounting.  If the admin does not want this,
> he should have a way to selectively disable it.
I believe we have that way already with the "canmount" property.

-- 
Darren J Moffat

Darren J Moffat wrote:
> Some background for context:
> 
> A given encrypted dataset my require either the pool level key 
> (keyscope=pool) or a key specific to that dataset (keyscope=dataset).
> 
> The commands to provide that key are ''zpool key -l
<pool>'' and ''zfs key
> -l <dataset>'' respectively.
> 
> When the pool is imported (or the system reboots) the key is not 
> automatically loaded and requires an explicit load (as above).  This 
> means that encrypted datasets are not automatically mounted at import/boot.
> 
> When the key is provided should the encrypted datasets be automatically 
> mounted  ?
> 
> For keyscope=dataset it would look like this:
> 
> $ zfs key -l tank/home/darrenm
> $ cd /tank/home/darrenm/
> 
> That is an easy case since we know explicitly which dataset you wanted 
> mounted so it seems obvious that the mount should be implicit if the key 
> load succeeded.
> 
> For keyscope=pool there could be many datasets that can now be mounted 
> that couldn''t previously:
> 
> # zpool key -l tank
> # zfs mount -a
> $ cd /tank/home/darrenm/
> 
> Question:  When we load a pool key should all encrypted datasets with 
> keyscope=pool be automatically mounted or should the admin have to 
> explicitly mount them by name or by using ''zfs mount -a''
?
> 
> 
> 
I think they should be automatically mounted.. My loading the key, you 
are asking for them to be mounted.  When a pool is imported they are 
automatically mounted, I didn''t see why this should be any different..

Tony

On Tue, Feb 26, 2008 at 3:45 PM, Darren J Moffat <Darren.Moffat at
sun.com> wrote:
> Some background for context:
>
>
>  Question:  When we load a pool key should all encrypted datasets with
>  keyscope=pool be automatically mounted or should the admin have to
>  explicitly mount them by name or by using ''zfs mount -a''
?
>
I''d like to add my voice in favor of automatically mounting affected
datasets
upon key loading. I believe that key loading is explicit enough action to
designate the intention to access the data. So we shouldn''t demand yet
another administrative step to get to the data.

-- 
Regards,
        Cyril

On Wed, Feb 27, 2008 at 7:48 AM, Cyril Plisko <cyril.plisko at
mountall.com> wrote:
> On Tue, Feb 26, 2008 at 3:45 PM, Darren J Moffat <Darren.Moffat at
sun.com> wrote:
>  > Some background for context:
>  >
>  >
>
> >  Question:  When we load a pool key should all encrypted datasets with
>  >  keyscope=pool be automatically mounted or should the admin have to
>  >  explicitly mount them by name or by using ''zfs mount
-a'' ?
>  >
>
>  I''d like to add my voice in favor of automatically mounting
affected datasets
>  upon key loading. I believe that key loading is explicit enough action to
>  designate the intention to access the data. So we shouldn''t
demand yet
>  another administrative step to get to the data.
I think that the latest development WRT canmount property [1]
may complement well what you trying to achieve here.
What do you think ?

[1]
http://mail.opensolaris.org/pipermail/opensolaris-arc/2008-February/006708.html
>
>  --
>  Regards,
>         Cyril
>


-- 
Regards,
        Cyril

On Wed, 2008-02-27 at 07:48 +0200, Cyril Plisko wrote:
> I''d like to add my voice in favor of automatically mounting
affected datasets
> upon key loading. I believe that key loading is explicit enough action to
> designate the intention to access the data. So we shouldn''t demand
yet
> another administrative step to get to the data.
I agree that in normal operation, automatically mounting the datasets
when the key is available makes a lot of sense.

There are times (generally when hardware appears to be misbehaving) when
I''d want to operate by baby steps, so having a way to defer the
auto-mount would be valuable, but the default should be to auto-mount.

						 - Bill

Bill Sommerfeld wrote:
> On Wed, 2008-02-27 at 07:48 +0200, Cyril Plisko wrote:
>> I''d like to add my voice in favor of automatically mounting
affected datasets
>> upon key loading. I believe that key loading is explicit enough action
to
>> designate the intention to access the data. So we shouldn''t
demand yet
>> another administrative step to get to the data.
> 
> I agree that in normal operation, automatically mounting the datasets
> when the key is available makes a lot of sense.
Thanks.

I also discovered that to it pretty much has to be this way for 
encrypted ZVOLs to work anyway because of how and when the ZVOLs come on 
line.

Also I discovered that not doing this would have mean''t I would have to
change the filebench code to support encrypted datasets (it needs to do 
a zpool export ; zpool import to flush data to disk and clear out the ARC).
> There are times (generally when hardware appears to be misbehaving) when
> I''d want to operate by baby steps, so having a way to defer the
> auto-mount would be valuable, but the default should be to auto-mount.
ZFS already has the canmount= property for doing this type of thing and 
it was very recently just updated to include an auto/vs no-auto distinction.

-- 
Darren J Moffat