[Pkg-cryptsetup-devel] TODO list

[Jonas Meurer]

On 02/02/2006 gebi at sbox.tugraz.at wrote:
> Quoting Jonas Meurer <jonas at freesources.org>:
> 
> >* provide support for LVM on encryped devices
> >  - check for existance of source device before running cryptsetup
> 
> Is it really necessary in the long term?
> What if we just implement better errorhandling in cryptsetup?

imagine the following scenario:
- physical partition /dev/hda2 is encrypted, dm-crypt device c_hda2
- lvm volume group "vg01" uses /dev/mapper/c_hda2 as physical volume (pv)
- lvm logical volume "lv_data" in vg01 is encrypted

this would require the following order in boot process:
1. cryptsetup {luksOpen,create} /dev/hda2 c_hda2
   [ create /dev/mapper/c_hda2 as a decrypted partition device ]
2. vgchange -a y vg01
   [ activate volume group vg01 with physical volume c_hda2 ]
3. cryptsetup {luksOpen,create} /dev/vg01/lv_data c_lv_data
   [ create /dev/mapperc_lv_data as a decrypted logical volume device ]
4. mount /dev/mapper/c_lv_data /mnt/data
   [ mount /dev/mapper/c_lv_data to mountpoint /mnt/data ]

you see, that cryptsetup needs to be run twice. once before lvm is
started (to configure the pv /dev/mapper/c_hda2), and once after lvm
is started (to configure the lv /dev/mapper/c_lv_data).

> >* improve the checks
> >  - distinguish between luks, plain cryptsetup and swap
> >   swap:
> >     + precheck for any existing filesystem, fail if possitive
> 
> really?
> if the partition has type swap, why should we care?
> every live-cd out there whipes a partition with mkswap if it is of  
> type swap (id 82).

and what about logical swap devices, like lvm etc.? in this case, a
partition id check is useless.
maybe we can first check whether partition has type swap. Only if this
is not true, check for an existant filesystem before running cryptsetup.

> >   plain cryptsetup:
> >     + precheck for any existing filesystem, fail if possitive
> 
> couldn't be avoided :(.

yes, maybe fsck -T /dev/device is a good idea, i don't know.

> >     + postcheck for the expected filesystem, fail if negative
> 
> couldn't be avoided also :(, or any other ideas?
> But why should we check if a mount does allready fail?
> print a warning for possible false pw or false partition?

yes. the user has to configure the expected filesystem anyway. if he/she
configures /usr to be reiserfs, we check for reiserfs. and if this check
fails, it indicates that either the pass/key is wrong, or the user
missconfigured his/her system.

> 
> why?
> if luksOpen succeeds it is the right data. Why sould we check if there  
> is a filesystem? Who says that there should be a filesystem on the  
> cryptovolume?

here, you're correct. i've updated the TODO.

...
 jonas