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
next prev parent 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.