[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Hey,

On 17/05/2011 Christoph Anton Mitterer wrote:
> On Mon, 16 May 2011 22:25:45 -0300, Henrique de Moraes Holschuh
> <hmh@debian.org> wrote:
> > Because the initscript returned status 0 when there were still
> > cryptsetup-managed dm-crypt devices active?  If it does that, it is
> > broken.
> AFAIU just this happens right now.

yes, and this is the way it's supposed to be:

- if the cryptsetup package is installed, the action stop will exit with
  $? != 0 in case any crypttab-listed dm-crypt device fails to stop
  (only the case for cryptdisks-early)

- if the cryptsetup package is removed but not purged, the initscript
  will exit with $? = 0 in any case, as neither the cryptsetup binary,
  nor the functions file at /lib/cryptsetup/cryptdisks.functions is
  available on the system.

> > Because the initscript returned status 0 when there were NO
> > cryptsetup-managed dm-crypt devices, but some other sort of dm-crypt
> > device?  The user should have known better.
> Actually I'm not sure on how /etc/init.d/cryptdisks and -early are
> intended with respect to this.
> Jonas, should they also handle (i.e. close) any unmanaged dm-crypt
> devices?
> Wouldn't be to bad, if stopping is just tried for any open device e.g. on
> shutdown, would it?

no, that's a very bad idea. actually, cryptsetup is *one* tool to manage
dm-crypt devices, it's not *the*only*one*. and it's a very very bad idea
to interfere in the dm-crypt management of other tools.

> > Note that I am against cryptsetup allowing itself to be removed while
> > devices *it manages* are still open in the first place.
> The more I think about it... the more I could like the idea,... but ONLY
> if it refuses to be removed if *any* dm-crypt device is still open.
> We really shouldn't make different grades of devices where one handled
> more important than the other.

cryptsetup is not like the kernel! several other tools (take a look at
cryptmount for example) might still be available, which allow the user
to manage unlocked (and locked) dm-crypt devices.

greetings,
 jonas

Attachment: signature.asc
Description: Digital signature


Reply to: