zfs crypto discuss - Mar 2008 - [Bug 783] New: keystatus property confused about persistence.

http://defect.opensolaris.org/bz/show_bug.cgi?id=783

           Summary: keystatus property confused about persistence.
    Classification: Development
           Product: zfs-crypto
           Version: unspecified
          Platform: Other
        OS/Version: Solaris
            Status: NEW
          Severity: minor
          Priority: P4
         Component: other
        AssignedTo: darrenm at opensolaris.org
        ReportedBy: darrenm at opensolaris.org
         QAContact: hua.tang at sun.com
                CC: zfs-crypto-discuss at opensolaris.org
   Estimated Hours: 0.0


The keystatus property only makes sense for an imported pool and as such
shouldn''t persist on disk.  It is similar to the mounted property.  The
present
implementation is showing keyscope=dataset keys as available after
reboot/import even when they haven''t been loaded (thats the bug here,
the rest
is design refinement).

For datasets with keyscope=dataset "undefined" is an invalid state it
can only
ever be "available" or "unavailable" because the key must be
provided at
creation time. After that the only valid states are "available" or
"unavailable".

For datasets with keyscope=pool again "undefined" is an invalid state
because
they can only be created if the pool key was present when they were created. 
After that the only valid states are "available" or
"unavailable".

For datasets the "undefined" state is only seen when encryption=off,
where it
is really representing "not applicable" (since this property can NOT
be
inherited).

"available" really means (dsl_dataset_t)->ds_key != NULL
"unavailable" really means (dsl_dataset_t)->ds_key == NULL

With the added minor complication that for keyscope=pool instead look at
(spa_t)->spa_key instead.


For the pool "undefined" is representing the fact that no pool key has
ever
been provided, either at inital pool creation time or later with ''zpool
key
-l''.  This distinction makes sense. However we don''t actually
need to persist
the "keystatus" property to implement that distinction because the
pool
property "keycheck" tells us if a pool key was ever defined.

To implement this we need to:

* Re-add the ioctl command for checking a dataset or pool key
* Make "undefined" never visible as a keystatus value for datasets
* For the pool "undefined" is returned when there is no keycheck value
present.

-- 
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://defect.opensolaris.org/bz/show_bug.cgi?id=783


Darren J Moffat <darrenm at opensolaris.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |CAUSEKNOWN




--- Comment #1 from Darren J Moffat <darrenm at opensolaris.org> 
2008-03-17 10:24:52 ---
It is worse than just confusion.

$ zfs get all tank/ds1
....
tank/ds1  encryption       on                     local
tank/ds1  keysource        passphrase,prompt      local
tank/ds1  keyscope         dataset                local
tank/ds1  keystatus        available              local

But we didn''t actually load the key all we did was reboot.

# zfs key -u tank/ds1

Now lets verify that happened:

# zfs get all tank/ds1 

Results in this:

panic[cpu0]/thread=ffffff05092a1c40: assertion failed: za.za_integer_length =8
(0x4 == 0x8), file: ../../common/fs/zfs/dsl_prop.c, line: 512

ffffff001f22b920 genunix:assfail3+b9 ()
ffffff001f22bbe0 zfs:dsl_prop_get_all+2ee ()
ffffff001f22bc20 zfs:zfs_ioc_objset_stats+5c ()
ffffff001f22bca0 zfs:zfsdev_ioctl+162 ()
ffffff001f22bce0 genunix:cdev_ioctl+48 ()
ffffff001f22bd20 specfs:spec_ioctl+86 ()
ffffff001f22bda0 genunix:fop_ioctl+7b ()
ffffff001f22beb0 genunix:ioctl+174 ()
ffffff001f22bf00 unix:brand_sys_syscall32+292 ()

-- 
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://defect.opensolaris.org/bz/show_bug.cgi?id=783


Darren J Moffat <darrenm at opensolaris.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P4                          |P1
           Severity|minor                       |blocker
             Blocks|                            |687, 674, 752




-- 
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://defect.opensolaris.org/bz/show_bug.cgi?id=783


Darren J Moffat <darrenm at opensolaris.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CAUSEKNOWN                  |CLOSED
         Resolution|                            |FIXED




--- Comment #2 from Darren J Moffat <darrenm at opensolaris.org> 
2008-04-02 06:28:21 ---
Fixed by the new in memory spa_keystore.

-- 
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.