> Message: 1 > Date: Mon, 17 Mar 2008 12:40:23 +0000 > From: Darren J Moffat <Darren.Moffat at Sun.COM> > Subject: [zfs-code] Property inheritance during dataset creation > To: zfs-code at opensolaris.org > Cc: zfs-crypto-discuss at opensolaris.org > Message-ID: <47DE66B7.1080408 at Sun.COM> > Content-Type: text/plain; format=flowed; charset=ISO-8859-1 > > Context: For the ZFS Crypto project we have a property keyscope that > determines wither or not the pool key or a per-dataset key should be used. > > For encryption=on and keyscope=pool we just require that the pool key > have been loaded already, and we can check that by looking at the > keystatus property on the pool. This works just fine. > > When creating datasets with keyscope=dataset we need to get the key > material *before* we call down to the kernel using ZFS_IOC_CREATE. If > encryption=off or keyscope=pool then there is nothing to do in terms of > getting keys. > > To do this I need to determine the value of the encryption > (PROP_ONETIME), keyscope (PROP_INHERIT) and keysource (PROP_INHERIT) > properties (in that order). If they are explicitly specified there is > no problem because the will be in the nvprops. However if they are to > be inherited they won''t be in nvprops since inheritance hasn''t happened > yet (since we are still in libzfs`zfs_create()).It may be a silly question, but if properties you need are to be inherited, why not just call into the kernel to create dataset w/o specifying them? Equivalently, why would one want to set properties to be inherited *before* inheritance happens? Some specific constraints imposed by ZFS Crypto design? Regards, Andrey
Andrey Kuzmin wrote:>> Message: 1 >> Date: Mon, 17 Mar 2008 12:40:23 +0000 >> From: Darren J Moffat <Darren.Moffat at Sun.COM> >> Subject: [zfs-code] Property inheritance during dataset creation >> To: zfs-code at opensolaris.org >> Cc: zfs-crypto-discuss at opensolaris.org >> Message-ID: <47DE66B7.1080408 at Sun.COM> >> Content-Type: text/plain; format=flowed; charset=ISO-8859-1 >> >> Context: For the ZFS Crypto project we have a property keyscope that >> determines wither or not the pool key or a per-dataset key should be used. >> >> For encryption=on and keyscope=pool we just require that the pool key >> have been loaded already, and we can check that by looking at the >> keystatus property on the pool. This works just fine. >> >> When creating datasets with keyscope=dataset we need to get the key >> material *before* we call down to the kernel using ZFS_IOC_CREATE. If >> encryption=off or keyscope=pool then there is nothing to do in terms of >> getting keys. >> >> To do this I need to determine the value of the encryption >> (PROP_ONETIME), keyscope (PROP_INHERIT) and keysource (PROP_INHERIT) >> properties (in that order). If they are explicitly specified there is >> no problem because the will be in the nvprops. However if they are to >> be inherited they won''t be in nvprops since inheritance hasn''t happened >> yet (since we are still in libzfs`zfs_create()). > > > It may be a silly question, but if properties you need are to be inherited, > why not just call into the kernel to create dataset w/o specifying them? > Equivalently, why would one want to set properties to be inherited *before* > inheritance happens? Some specific constraints imposed by ZFS Crypto design?I think you have misunderstood what I''m saying, so let me give some examples: $ zfs create -o encryption=aes-128-ccm tank/home $ zfs create tank/home/darrenm $ zfs create -o keyscope=dataset -o keysource=passphrase,prompt \ tank/home/darrenm/Documents Enter passphrase for tank/home/darrenm/Documents: *********** Re-enter passphrase for tank/home/darrenm/Documents: *********** $ For the first two filesystems keyscope is the default which is pool. They just require that the pool key is available to create them. For the third case I''m inheriting the encryption property but overriding the keyscope to dataset and since I set keyscope I need to set keysource because it isn''t set in any of parents to inherit it from. The issue is that to generate the key encryption key out of the passphrase (using PKCS#5 PBE) I need to know what the value of the encryption= property is because that tells me the algorithm and keylength (and the mode). However we are still in userland at this point and inheritance doesn''t happen until we are in the DMU layer in kernel. If keyscope=pool then we don''t have this isssue as we don''t need any keys generated in or passed down from userland. I''ve coded around this by finding out what the parent dataset is and looking up the properties there. This seems to be working fine so far, I was just looking for a better way. -- Darren J Moffat
> -----Original Message----- > From: Darren.Moffat at Sun.COM [mailto:Darren.Moffat at Sun.COM] > Sent: Wednesday, March 19, 2008 5:40 PM > To: andrey.v.kuzmin at gmail.com > Cc: zfs-code at opensolaris.org > Subject: Re: zfs-code Digest, Vol 22, Issue 3 > > > I think you have misunderstood what I''m saying, so let me give some > examples: > > $ zfs create -o encryption=aes-128-ccm tank/home > $ zfs create tank/home/darrenm > $ zfs create -o keyscope=dataset -o keysource=passphrase,prompt \ > tank/home/darrenm/Documents > Enter passphrase for tank/home/darrenm/Documents: *********** > Re-enter passphrase for tank/home/darrenm/Documents: *********** > $ > > For the first two filesystems keyscope is the default which is pool. > They just require that the pool key is available to create them. > > For the third case I''m inheriting the encryption property but overriding > the keyscope to dataset and since I set keyscope I need to set keysource > because it isn''t set in any of parents to inherit it from.In the third case you can do create w/o setting overridden properties to inherit encryption, and then override necessary properties as well. Or there''s no way to override crypto-properties once set? Regards, Andrey
Andrey Kuzmin wrote:>> -----Original Message----- >> From: Darren.Moffat at Sun.COM [mailto:Darren.Moffat at Sun.COM] >> Sent: Wednesday, March 19, 2008 5:40 PM >> To: andrey.v.kuzmin at gmail.com >> Cc: zfs-code at opensolaris.org >> Subject: Re: zfs-code Digest, Vol 22, Issue 3 >> >> >> I think you have misunderstood what I''m saying, so let me give some >> examples: >> >> $ zfs create -o encryption=aes-128-ccm tank/home >> $ zfs create tank/home/darrenm >> $ zfs create -o keyscope=dataset -o keysource=passphrase,prompt \ >> tank/home/darrenm/Documents >> Enter passphrase for tank/home/darrenm/Documents: *********** >> Re-enter passphrase for tank/home/darrenm/Documents: *********** >> $ >> >> For the first two filesystems keyscope is the default which is pool. >> They just require that the pool key is available to create them. >> >> For the third case I''m inheriting the encryption property but overriding >> the keyscope to dataset and since I set keyscope I need to set keysource >> because it isn''t set in any of parents to inherit it from. > > > In the third case you can do create w/o setting overridden properties to > inherit encryption, and then override necessary properties as well.No I can''t. > Or there''s no way to override crypto-properties once set? You can''t change the encryption property on an already created dataset - fundamental to the design. I also can''t change the format part of keysource (only the locator part). The keyscope can be changed but only as part of doing an explicit ''zfs key -c -o keyscope='' which you can''t do until after the dataset is created. -- Darren J Moffat