| Summary: | Cryptmount fails on LUKS devices after mga5 upgrade: 'Cannot find key-manager to match target' | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Ardonik Jones <mageia> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, herman.viaene, lewyssmith, luismago, sysadmin-bugs |
| Version: | 5 | Keywords: | validated_update |
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | advisory MGA5-64-OK | ||
| Source RPM: | cryptmount-5.0-4.mga5.src.rpm | CVE: | |
| Status comment: | |||
| Attachments: |
Add luks support to cryptmount-5.0
Test example using cryptmount-setup |
||
The problem seems to stem from the fact that the Mageia 5 version of cryptmount is not built with support for the LUKS key-manager. Here's my Mageia 4 box: [ardonik@dumptruck ~]$ cat /etc/release ; cryptmount -k ; cryptmount --version Mageia release 4 (Official) for i586 builtin, password, libgcrypt, openssl-compat, luks, raw cryptmount-4.4.1 Here's my Mageia 5 box: ardonik@zar:~[18]$ cat /etc/release ; cryptmount -k ; cryptmount --version Mageia release 5 (Official) for i586 builtin, password, libgcrypt, openssl-compat, raw cryptmount-5.0 I can't see anything in the cryptmount changelogs indicating why the new version was built this way. Thanks for the report. Assigning to our maintainer for cryptmount. Assignee:
bugsquad =>
guillomovitch Well, I think this bug is caused by a build depencency issue. Looking at the configure script output, it looks like luks support needs both libgcrypt-devel *AND* libcryptsetup-devel installed when building the package. However, currently there is no "BuildRequires: libcryptsetup-devel" in spec file. So I installed libcryptsetup-devel (as well as the other BuildRequires dependencies), then rebuild the binary rpm from the source rpm, and now luks support is ok: $ cryptmount -k builtin, password, libgcrypt, openssl-compat, luks, raw I made a test with a luks encrypted file and everything worked as expected. I just submitted a fixed release in updates_testing for mageia 5. QA team, here is a suggested advisory: The cryptmount package shipped in mageia 5 was missing LUKS format support, due to a missing build dependency. cryptmount 5.0-4.1.mga5, available in updates_testing, fixes this issue. Status:
NEW =>
ASSIGNED
Dave Hodgins
2015-10-13 19:09:17 CEST
CC:
(none) =>
davidwhodgins MGA5-32 on AcerD620 Xfce. Installed first old cryptmount. Problem following testprocedure above: at CLI as root dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10 10+0 records read 10+0 records written 10485760 bytes (10 MB) copied, 0,0411205 s, 255 MB/s [root@mach6 ~]# /sbin/losetup --verbose --find --show /tmp/disk.img /dev/loop0 [root@mach6 ~]# cryptsetup luksFormat /dev/loop0 # Or whatever was printed previously WARNING! ======== This will overwrite data op /dev/loop0 . Are you sure? (Type uppercase yes): Y [root@mach6 ~]# cryptsetup -v luksOpen /dev/loop0 bug-test Apparaat /dev/loop0 is not a valid LUKS-device. Task fails with code 22: Device /dev/loop0 is not a valid LUKS-device. The wording might not be a 100% correct, since I am running in Dutch, so I had to translate the words CC:
(none) =>
herman.viaene Trying M5 x64 real hardware. Installed PRE-update: cryptmount-5.0-4.mga5 Following the excellent steps described in Description/Comment 0, I fell into the same hole as Herman, Comment 6: # dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.0232013 s, 452 MB/s # /sbin/losetup --verbose --find --show /tmp/disk.img /dev/loop0 # cryptsetup luksFormat /dev/loop0 WARNING! ======== This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): Y [it says *upper case* Y, but the outcome was the same with 'y']. # cryptsetup -v luksOpen /dev/loop0 bug-test Device /dev/loop0 is not a valid LUKS device. Command failed with code 22: Device /dev/loop0 is not a valid LUKS device. What next? Setting feedback marker. CC:
(none) =>
lewyssmith When it prompts "Type uppercase yes", try to enter YES, and see if it works. A little bit unintuitive, but it's an oddity of cryptsetup. Testing M5 x64 real h/w. (In reply to LuismaGo from comment #8) > When it prompts "Type uppercase yes", try to enter YES, and see if it works. > A little bit unintuitive, but it's an oddity of cryptsetup. Thanks for this pointer. Silly us: do exactly what it says, and Bingo! Before trying the update, I note here what happens next, because your excellent instructions do miss some things. I repeat all the steps, with their output, for future reference. PRE-update: cryptmount-5.0-4.mga5 1. # dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.0230292 s, 455 MB/s # /sbin/losetup --verbose --find --show /tmp/disk.img /dev/loop0 # cryptsetup luksFormat /dev/loop0 WARNING! ======== This will overwrite data on /dev/loop0 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: [This flumoxed me at first: I thought it was wanting a pre-defined passphrase. I then realised that it is asking to *define* one. I used bare <Enter>]. Verify passphrase: 2. # cryptsetup -v luksOpen /dev/loop0 bug-test Enter passphrase for /tmp/disk.img: Key slot 0 unlocked. Command successful. # /sbin/mkfs -t ext4 -m 0 -j /dev/mapper/bug-test mke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 8192 1k blocks and 2048 inodes Allocating group tables: done Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done 3. # mkdir /tmp/cryptfolder 4. # vi /etc/cryptmount/cmtab [As described in Step 4]. 5. # cryptmount bug-test Cannot find key-manager to match target "bug-test" [The bug! Well done]. 6. # mount -t ext4 /dev/mapper/bug-test /tmp/cryptfolder -o defaults,user,acl # ls /tmp/cryptfolder lost+found/ Now to try the update with this acquired wisdom. Whiteboard:
advisory feedback =>
advisory Testing x64 (continued) Need advice about how to clear out everything created above. I umount'd [cryptmount -u did not work] and deleted /tmp/cryptfolder/ and /tmp/disk.img; and re-booted to re-start from scratch. (If you re-start within the same session, /dev/loop0 increments). POST-update: cryptmount-5.0-4.1.mga5 Re-running steps 1-4 was identical to previously. Step 5 was different, *not* showing the given PoC, but not successful either: # cryptmount bug-test Enter password for target "bug-test": device-mapper: create ioctl on bug-test failed: Device or resource busy device-mapper task failed Device-mapper target-creation failed for "bug-test" # ls -l /tmp drwxr-xr-x 2 root root 40 Hyd 27 21:03 cryptfolder/ [empty] -rw-r--r-- 1 root root 10485760 Hyd 27 21:02 disk.img I hope this is the result of something left over from the pre-update test cycle, but need feedback about the outcome and how to circumvent the error. @LuismaGo
Lewis Smith
2015-10-28 09:38:20 CET
Whiteboard:
advisory =>
advisory feedback (In reply to Lewis Smith from comment #10) > POST-update: cryptmount-5.0-4.1.mga5 > Re-running steps 1-4 was identical to previously. > Step 5 was different, *not* showing the given PoC, but not successful either: > # cryptmount bug-test > Enter password for target "bug-test": > device-mapper: create ioctl on bug-test failed: Device or resource busy > device-mapper task failed > Device-mapper target-creation failed for "bug-test" > [...] > I hope this is the result of something left over from the pre-update test > cycle, but need feedback about the outcome and how to circumvent the error. I followed the steps above and have been able to reproduce the same error. Along the process this is what happens: # /sbin/losetup --verbose --find --show /tmp/disk.img This associates the disk image to a loopback device # cryptsetup -v luksOpen /dev/loop0 bug-test A device named /dev/mapper/bug-test is created. We can now mount and umount this device as root, using the mount command. But cryptmount needs to work from scratch. That's to say, no /dev/mapper device created neither loopback device associated to the disk image. So, once the filesystem is formatted, some cleaning is needed for cryptmount to work. This can be done manually: 1. cryptsetup luksClose bug-test 2. losetup --detach /dev/loop0 Or else let cryptmount itself to do the "hard work": 1. cryptmount --release bug-test Whichever method is ok, and makes the mounting/umounting possible: # cryptmount bug-test Enter password for target "bug-test": e2fsck 1.42.12 (29-Aug-2014) /dev/mapper/bug-test: clean, 11/2048 files, 1330/8192 blocks # cryptmount -u bug-test # And as an unprivileged user: $ cryptmount bug-test Enter password for target "bug-test": e2fsck 1.42.12 (29-Aug-2014) /dev/mapper/bug-test: clean, 11/2048 files, 1330/8192 blocks $ ls /tmp/cryptfolder lost+found/ $ cryptmount -u bug-test $ Created attachment 7176 [details]
Test example using cryptmount-setup
The testing procedure is incorrect. Using cryptmount-setup, the programs
are working properly.
Sorry, ignore comment 12. That wasn't using luks. With the update. As root ... [root@x3 ~]# dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.00481259 s, 2.2 GB/s [root@x3 ~]# cryptsetup luksFormat /tmp/disk.img WARNING! ======== This will overwrite data on /tmp/disk.img irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase: Verify passphrase: [root@x3 ~]# cryptsetup -v luksOpen /tmp/disk.img bug-test Enter passphrase for /tmp/disk.img: Key slot 0 unlocked. Command successful. [root@x3 ~]# mkfs -t ext4 -m 0 -j /dev/mapper/bug-test mke2fs 1.42.12 (29-Aug-2014) Creating filesystem with 8192 1k blocks and 2048 inodes Allocating group tables: done Writing inode tables: done Creating journal (1024 blocks): done Writing superblocks and filesystem accounting information: done [root@x3 ~]# cryptsetup luksClose bug-test [root@x3 ~]# chown dave:dave /tmp/disk.img As user ... [dave@x3 ~]$ mkdir /tmp/cryptfolder [dave@x3 ~]$ cryptmount bug-test Enter password for target "bug-test": e2fsck 1.42.12 (29-Aug-2014) /dev/mapper/bug-test: clean, 11/2048 files, 1330/8192 blocks Keywords:
(none) =>
validated_update An update for this issue has been pushed to Mageia Updates repository. http://advisories.mageia.org/MGAA-2015-0164.html Status:
ASSIGNED =>
RESOLVED I just want to say that you guys are awesome. Thank you for fixing this. |
Description of problem: Entries in /etc/cryptmount/cmtab that contain 'keyformat=luks' can't be mounted with cryptmount in Mageia 5, even though they were mountable with Mageia 4's cryptmount package. Version-Release number of selected component (if applicable): cryptmount-5.0 How reproducible: Every time. Steps to Reproduce: 1. Format a 10MiB disk image as an encrypted LUKS container: dd if=/dev/zero of=/tmp/disk.img bs=1MiB count=10 sudo /sbin/losetup --verbose --find --show /tmp/disk.img sudo cryptsetup luksFormat /dev/loop0 # Or whatever was printed previously 2. Format container as ext4: sudo cryptsetup -v luksOpen /dev/loop0 bug-test sudo /sbin/mkfs -t ext4 -m 0 -j /dev/mapper/bug-test 3. Make a mount folder: mkdir /tmp/cryptfolder 4. Add a cryptmount entry for the disk image in /etc/cryptmount/cmtab: bug-test { dev=/tmp/disk.img fstype=ext4 dir=/tmp/cryptfolder keyformat=luks } 5. Confirm that mounting with cryptmount fails. $ cryptmount bug-test Cannot find key-manager to match target "bug-test" 6. ...Even though mounting by hand works fine. $ sudo mount -t ext4 /dev/mapper/bug-test /tmp/cryptfolder -o defaults,user,acl $ ls /tmp/cryptfolder lost+found/ Reproducible: Steps to Reproduce: