cryptsetup bug in -current

Rupa · 05-24-2010, 03:08 AM

Hello!

I have several external hard disks with one encrypted partition (using cryptsetup luks).

In both KDE and XFCE, if I connect one of those drives, a window pops up to enter my passphrase. After entering the passphrase the filesystem inside the crypto partition became availabe to KDEs or XFCEs volume- and/or filemanager with it's label and one was able to mount or dismount it.

This stopped working after the cryptsetup upgrade from April 30. The window to enter the passphrase does appear and after entering the passphrase the drive gets 'unlocked' (it's listed in /dev/mapper), but nothing appears in dolphin or thunar or those panel plugins to manage drives.

It seems that HAL is not notified anymore about the new filesystem available. Restarting HAL and then restarting the DE does help.

Reverting back to cryptsetup before April, 30, does solve this issue.

One difference between those versions is that cryptsetup 1.0.7 names the decrypted devices as /dev/dm-N (where N is a sequential number) and puts a softlink in /dev/mapper whereas verion 1.1.0 makes the decrypted device directly available in /dev/mapper. Don't know if this might has something to do with the regression in DEs...

Can anyone confirm this issue?

GazL · 05-24-2010, 04:23 AM

Hmm, /dev/mapper is definitely different.

Code:

gazl@nix:~$ ls -l /dev/mapper
total 0
crw-rw---- 1 root root  10, 61 2010-05-24 09:39 control
brw-rw-r-- 1 root disk 253,  8 2010-05-24 10:02 lukssda3
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 lukssda5 -> ../dm-0
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvhome -> ../dm-6
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvlocal -> ../dm-7
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvopt -> ../dm-3
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvroot -> ../dm-1
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvtmp -> ../dm-5
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvusr -> ../dm-2
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvvar -> ../dm-4
gazl@nix:~$ ls -l /dev/dm-0
brw-rw---- 1 root disk 253, 0 2010-05-24 09:39 /dev/dm-0
gazl@nix:~$

lukssda5 was unlocked by cryptsetup in the initrd.
lukssda3 was unlocked manually by root using /usr/sbin/cryptsetup on a running system.

I'm also a little concerned about that others 'read' permission that seems to have crept in on lukssda3. Filesystem block devices don't normally allow that.

On my setup Dolphin shows a "encrypted device container" entry in the 'places' sidebar for my already unlocked lvm PV, with an option to unmount it. That really seems dodgy to me and it needs to filter these out somehow in the same way that it doesn't list partitions mounted from /etc/fstab. Maybe a check to see if an open luks mapping name refers to a pv in an active lvm vg needs to be added. Not sure how you'd go about making it that intelligent though. Might have a dig.

I've got a spare partition sitting about so I'll give unlocking a try from dolphin and report back.

Rupa · 05-24-2010, 04:42 AM

Thx GazL for your reply. Do you run -current with cryptsetup from after April, 30th? It doesn't seem so for me... The behaviour in dolphin you describe is what it used to be. After this upgrade my internal (already mounted) crypto partitions disappeared from dolphin. But as I don't care much about this, the problem reported here was only about external (removable) media which HAL isn't notified about.

GazL · 05-24-2010, 04:44 AM

Update:
Yes, the filesystem doesn't show up once the container is unlocked here either.

Rupa, I'm running a fully uptodate 64current.

GazL · 05-24-2010, 10:00 AM

After digging around in the internals of hal/udev a little this afternoon, I think I'm going back to WINDOWS!!! MY GOD! What a convoluted, tangled up ball of string it is!

The concept of udev is fine, but the implementation and how the various rules files indirectly affect each other by setting/passing obscure variables, cookies, calling external programs etc is just ugliness incarnate! And that's before you even get to the ugliness that is hal!

Anyway, from what I can see the udev rules that handle dm devices seem to be creating two device nodes: the usual one /dev/dm-n and then another one in /dev/mapper that should be a symlink to it.

Code:

gazl@nix:~$ ls -l /dev/dm-8 /dev/mapper/lukssda3
brw-rw---- 1 root disk 253, 8 2010-05-24 15:54 /dev/dm-8
brw-rw-r-- 1 root disk 253, 8 2010-05-24 15:54 /dev/mapper/lukssda3

And as you can see the additional node in /dev/mapper has the wrong permissions (probably because it shouldn't be being created there in the first place)

Looks like a udev bug.

GazL · 05-25-2010, 06:40 AM

Looks like this is fixed upstream in cryptsetup 1.1.1.
udev support was new in 1.1.0. Looks like a few bugs crept in.

I also tried adding the --disable-udev configure option, but that just seemed to break it again.

If you're running your rootfs on an encrypted volume and unlocking anything in your initrd, don't forget to rebuild your initrd and rerun lilo after updating as that also contains a copy of cryptsetup.

rworkman · 05-25-2010, 01:05 PM

Pardon the posting from Windows, but I'm at work and that's all I can get online with here, but I just upgraded cryptsetup on my laptop and it still doesn't work for me. There's some improvement in that I'm only asked for the passphrase *once* instead of twice, but I still get no icon and no automount in Xfce.

I think this might be an issue with thunar-volman actually, but I don't know C well enough to wade through all of it.

If someone is on IRC and can join #claws-mail on freenode, see if colinl (Colin Leroy) is around and might be willing to help -- he wrote the initial patches to get encrypted device support in Xfce.

GazL · 05-25-2010, 01:54 PM

I tried it under KDE/dolphin and the upgrade certainly seemed to fix volume unlocking on that, plus it fixed the permissions and the symlink was back again in /dev/mapper.

I don't use XFCE and I assumed it would be the same issue. My bad.

Do you get a symlink again in /dev/mapper for the mapping device or is it still showing a device node?

One thing I did notice was that if you'd used the old version of cryptsetup prior to the new then it tended to cause problems. I think it must leave some sort of 'state' in the kernel somewhere. It wasn't until after I'd rebuilt mkinitrd (to take a fresh copy of cryptsetup) and rebooted that it seemed to settle down for me.

My encrypted partition is on my fixed disk and I can't see a way to unlock that from XFCE. It seems the volume manager thingy is only for "removable" media.

rworkman · 05-25-2010, 02:09 PM

The /dev/mapper/ file is indeed a symlink. This was with a rebuilt initrd and a reboot. Yes, the volume manager only deals with removable devices.

I'll try to catch Colin online soonish and hope he's not swamped too :/

GazL · 05-25-2010, 02:24 PM

Ok, It looks like there's multiple problems going on here. I just tried again under KDE/dolphin and the first 2 times it worked, but then it stopped working again.

I've noticed that when it stops working syslog contains the following right after the 'open' from dolphin.

Code:

May 25 20:12:50 nix kernel: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-2175

and once it's got in this state, trying to do a luksOpen (after closing the previous mapping) from the commandline gives a

Code:

oot@nix:~# cryptsetup luksOpen /dev/sda3 lukssda3
Enter passphrase for /dev/sda3: 
device-mapper: remove ioctl failed: Device or resource busy
Key slot 0 unlocked.
root@nix:~#

So, 1.1.1 fixes the symlink thingy, but there's still something very broken going on, and it doesn't look like it's a kde or xfce issue.

rworkman · 05-25-2010, 02:54 PM

Hrm, I have an idea (from talking quite some time ago with Kay Sievers). Basically, upstream lvm/dm guys and upstream udev guys disagree on some implementation details, and we might be seeing some fallout from that.

In one of the lvm udev rules (10-dm.rules iirc), there's line that has STARTUP=1 in it that sets NAME="" (this is from memory) -- try commenting out that line completely. If that doesn't make sense right now, don't do anything until I can actually sit down in front of a machine and see the text...

GazL · 05-25-2010, 03:10 PM

Yes, I was wondering about that stuff too when I was looking at it yesterday and it was that file that triggered my little mini-rant about udev getting way too complicated. I wasn't really comfortable changing it though as I didn't understand how it all fit together. I think you're right on this being a bad interaction between cryptsetup and the dm/lvm udev rules.

Just as a final bit of info on this. I just rebooted and did a cryptsetup from the command line straight away and still got the:

Code:

device-mapper: ioctl: unable to remove open device temporary-cryptsetup-1830

So, whether it works or not seems somewhat random at the moment.

conraid · 05-26-2010, 05:41 AM

For usb crypt partition

Code:

# cryptsetup luksOpen /dev/sdb2 hdcrypt
Enter passphrase for /dev/sdb2: 
device-mapper: remove ioctl failed: Device or resource busy
Key slot 0 unlocked.

In a lvm partition i have similar error, only if I run cryptsetup while booting, (/etc/crypttab) everything is ok, but if I try to open it later by mistake

GazL · 05-28-2010, 03:39 PM

Right, I've managed to get this working by:

upgrading cryptsetup to 1.1.1 and udev to 156.

It still throws out the ioctl remove failed: device is busy message, but that seems to be a known problem upstream and doesn't actually affect the locking/unlocking.

I'd also upgraded lvm to 2.02.66 but I don't think that actually mattered.

Anyway, I've dropped Pat a line about this, so hopefully we might see some patches to fix this turn up.

rworkman · 05-28-2010, 10:06 PM

Still the same here, so udev isn't the magic bullet.