Re: RC1/2 misbehaviour (bug?)

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

 



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@xxxxxxxxxx
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux