[pkg-cryptsetup-devel] Bug#626641: cryptsetup: bug #587220 re-introduced

[Christoph Anton Mitterer]

On Mon, 16 May 2011 22:35:12 -0300, Henrique de Moraes Holschuh
<hmh at debian.org> wrote:
> Then, 'stop' tries to close all managed crypto devices and aborts *with
> an error* if it cannot.  'Start' tries to open all managed crypto
> devices, and aborts *with an error* if it cannot.
> 
> And 'restart' should not be supported, and return with the appropriate
> error, or it could just be stop+start.  You likely don't want to run
> this on package upgrades.
> 
> You'd still have to call 'stop' and abort the package removal in prerm
> [when removing the package. You will have to diferentiate the various
> reasons for why prerm is called] if it cannot close all crypto devices
> it manages.  And 'start' on postinst, of course.

I'm not totally sure why, but also don't like the idea calling these from
the maintainer scripts.
Especially (but I'm not sure on this) as it might ignore any
non-crypttab-managed dm-crypt devices.


Still, the IMHO best solution would be:
- let any scripts fail with $? != 0 if the action they're expected to
perform failed
  => this however does not comply with the crude Debian init-scripts
policy
AND
- if cryptsetup is removed OR purged, give a big fat debconf-prio-low
warning that devices a b c are still open, and cannot be closed using
cryptsetup, if the user decides to continue.


Then we've warned/instructed the interactive user and we've also secured
any (clean[0]) script usage of the scripts within the cryptsetup package.


> Well, I think it is not appropriate to even let the package get removed
> in the first place if there are devices still open.
This would make removal of the package impossible, if you e.g. use
dm-crypt for the root-fs.


Happy hacking,
Chris.


[0] Of course we cannot force any users to check the exit codes,.. but
this is then really their fault.