All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] RC1/2 misbehaviour (bug?)
Date: Fri, 09 Oct 2009 12:47:42 +0200	[thread overview]
Message-ID: <4ACF14CE.1060802@redhat.com> (raw)
In-Reply-To: <20091009074743.GA7885@fancy-poultry.org>

On 10/09/2009 09:47 AM, Heinz Diehl wrote:
> Hi,
> 
> when recreating and assigning a new keyfile to a deleted keyslot, I'm getting asked
> for an existing passphrase _two times_ :
> 
>  liesel:/home/htd # cryptsetup luksAddKey /dev/sda3 test.txt --key-slot 0
>  Enter any passphrase: 
>  Verify passphrase:
> 
>>From time to time, a warning from device-mapper appears when creating a new
> LUKS partition, saying:
> 
>  device-mapper: ioctl: unable to remove open device...
>  
> Both issues happens with RC1 and RC2. Just to let you know ;-)

This is bug but not in cryptsetup.

Someone (probably from udev rule) scan all new devices - here temporary cryptsetup
keystore device.

It must not open these device types, usualy udev rule should contain something like

ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_last_rule"
ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="dm_last_rule"

Run cryptsetup with --debug and also check syslog and you will see that it retries
the remove.

You will probably find error that temporary-cryptsetup-$PID device is open and cannot
be removed. Please report it to your distro as bug, you will need check who opened
this device (I guess it is blkid from some generic udev rule)

(This problem was quietly hidden in previous crypestup, because there was 1 second delay
before remove which was enough to hide this dangerous scan.)

Maybe I should add some message to debug about proces name opening that internal device...

Note that it is possible security problem - keystore device contains hashed master
key, no other process except cryptsetup should read that (and store anywhere in
unlocked memory).

(But some rules were written such way, that it scan all new devices in system.
Also it must not react to "add" event but only to "change" event in the case of DM devices.
See lvm & dm list devel for more info if needed, there are already bugs at least
for Debian and Fedora reported. Finally it will be solved by switching to udev rules from
lvm package which will be maintained by lvm/dm developers.)

Milan
--
mbroz@redhat.com

  reply	other threads:[~2009-10-09 10:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-09  7:47 [dm-crypt] RC1/2 misbehaviour (bug?) Heinz Diehl
2009-10-09 10:47 ` Milan Broz [this message]
2009-10-09 12:04   ` Heinz Diehl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ACF14CE.1060802@redhat.com \
    --to=mbroz@redhat.com \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.