Quoting Jonas Meurer <[EMAIL PROTECTED]>:
if you encrypt a luks parition with a key, postchecks can be useful. if
you use a password, it is just like you said, it fails if the password
is wrong. but if you use a key, it doesn't fail if the key is wrong,
does it? otherwise keys like /dev/(u)random would not work.
/dev/urandom does not work with luksOpen...
only after a luksFormat, thats why i restricted my version of
cryptdisks to either swap _or_ luks, because luks is useless in this
usage scenario.
yes, but generally prechecks are run against the _source_ device, and
postchecks are run against the _target_ device, which is created by
cryptsetup.
Yes but where is the difference?
both are devices and both should be checked if there is a filesystem.
true, that's why i think that postchecks for swap are useless. does a
luksOpen already write to the device? in other words, does a
'cryptsetup -d /etc/keys/first_disk luksOpen /dev/hda1 first_disk'
damage a filesystem on /dev/hda1 if there existed one?
luksOpen does only succeed if there is the right key.
Just as i said... we don't need checks with luks.
Check if the partition exists (and even there we should be very carefully).
Check if it is a luks partition with isLuks, if yes luksOpen it.
If the user gave as the wrong key, it's not our fault (thats another
bug for right error messages against cryptsetup).
IMHO we _should_NOT_ postcheck a successfully mapped luks partition
because, if it opens successfully it is the right data, if not the
password was wrong (there is no other way).
i don't know if it's a good idea to check all source devices for x
filesystems before starting cryptsetup. imagine how many filesystems
exist, and ideally we would have to check for all of them.
How would you check if there is a filesystem on the partition? (if not
trying all known filesystems?).
but first we want to check for a filesystem on the source device, and
fail if one exists.
Yes that requires a check against all known filesystems... and even
then it's possible that there is an unknown filesystem on the device.
Trying to mount is also a no-option, because even a ro mount would
touch the filesystem (journaling).
then we start cryptsetup (if we didn't fail because
of the precheck), and afterwards check whether a filesystem exists on
the target device. in other words, if we run
'cryptsetup {luksOpen,create} /dev/hda1 first_disk' ...
we previously check whether /dev/hda1 has a filesystem. if it has, we
fail, as we don't want to damage the filesystem.
if /dev/hda1 has no filesystem, we run the cryptsetup command, and after
that has happened, we check whether /dev/mapper/first_disk has the
expected filesystem. if yes, all is ok, if no, we remove the dm-crypt
device again, as we didn't get the wished result.
sorry...
but postchecking luks is useless, because with the false key luksOpen
does not succeed.
Cryptdisks is for mapping the devices, not for spying onto the user if
he is able to format his crypto-volumes right (imho).
It's _impossible_ to know what the user stores onto his cryptovolumes.
the only dangerous things are the old cryptsetup volumes, and
_espacially_ the swap option in cryptdisks, because it actually
formats the partition.
ok i'll write a small paper about that till tomorrow, because there is
too much information for email conversation.
greets,
Michael Gebetsroither
