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

Jonas Meurer jonas at freesources.org
Tue May 17 11:48:06 UTC 2011


On 17/05/2011 Christoph Anton Mitterer wrote:
> 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.
> > 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.

I disagree with Henrique here. Christoph is right: It's a bad idea do
start/stop the cryptdisks initscript from debian maintainer scripts.
This is for several reasons:

- cryptsetup is not the only userspace tool which manages dm-crypt
  devices. Low-level tools like dmsetup, udev, hal; commandline tools
  like cryptmount and gui applications like gnome-mount etc. might
  unlock/lock encrypted devices as well.
- the cryptdisks initscript only manages dm-crypt devices which are
  listed in the crypttab. Therefore otherwise unlocked devices are
- for most setups, the solution that Henrique suggested, would mean that
  cryptsetup fails to be removed/purged. usualle the unlocked dm-crypt
  devices are mounted if the system is running, maybe even as root

> 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

Sorry Christoph, but this is simply not an option.

> - 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.

At the moment I consider this as the best solution.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20110517/47c71e5d/attachment.pgp>

More information about the pkg-cryptsetup-devel mailing list