Quoting Jonas Meurer <[EMAIL PROTECTED]>:

sure, there is.
prechecks are run against the source device, _before_ cryptsetup is started.
postchecks are run against the target device, _after_ cryptsetup is started.

Yes, but what should the script look like?
Imho there are 3 different branches (swap, plain cryptsetup, luks)

For swap:
precheck:
- should check if there is an known filesystem on the partition (execution of all checks)
postcheck:
- hmm.... what should be checkt in this stage for swap? (don't know of anything usefull)

For plain cryptsetup other than swap:
precheck:
  - same as with swap
postchecks:
  - should check if there is the wanted filesystem

For luks:
precheck:
  - first check if it is a valied luks partition, if yes -> fine
  - if it's not a valied luks partition, bye
postchecks:
  - shouldn't be necessary, because it can't be mapped with a false password.

But IMHO there is no difference between pre- and postchecks (the checks itself), only the interpretation of the return falues are different. All checks are generic filesystem checks, that check if there is a valied filesystem.

no, that is what a postcheck should do. start cryptsetup, check for a
swap partition, and run swapon only if the check succeeds.

Imho we shouldn't overcheck things. If we have allready written to the device it makes no sense to check it, because data on the disk is allready gone.
Just let swapon fail.

prechecks can verify that a device exists,

Yes this should imho the first check...
/lib/cryptsetup/devicecheck or somthing

and check for a
filesystem/swap partition _before_ cryptsetup is run.

Yes... that includes running all filesystemchecks on the device (if devicecheck succeeds).

But imho there is no sense in splitting up the checks in pre/post-checks, because we only want to check for a filesystem, which is independent from pre/post.

this can prevent
non-encrypted filesystems from being overwritten.
in my eyes, prechecks aren't that useful. at least with LUKS, they are
rather useless. but with plain cryptsetup (which doesn't check whether
the source device is an encrypted one at all) they still can help.

see above

greets,
Michael Gebetsroither




Reply via email to