LUKS-encrypted CDROM / DVD ROM are detected but mounting fails

[Ari]

I am creating LUKS-encrypted "crypto dvds" and "crypto cds" basically with the script found here:

http://gentoo-wiki.com/HOWTO_Burn_Encrypted_Optical_Media_With_Luks#Automation

I can manually mount and umount win no problems the encrypted optical media, using the helper mount/umount scripts which just do a "cryptsetup luksOpen" etc.

This seems to indicate that the LUKS volumes are fine. I have various other LUKS partitions in HD and USB that I use daily without a glitch.

The whole CD encryption and manual mounting process works fine. However, when I insert an encrypted CD, gnome-mount detects that it is an encrypted CD and prompts me for the password. I put the correct password and then hit enter. Then the password prompt dialog window freezes for about 4 minutes, after which I get an error message suggesting that the password was incorrect. If I enter my password again, the window freezes again.

If I just hit Cancel at the password prompt, and the mount the encrypted CD by hand, everything works fine.

If this gets fixed, when I insert an encrypted CD I would just get prompted for the password, and if the password is correct the cd would be mounted to /media/cdrom , which would be awesome.

Perhaps this bug is the same as: Bug #117011 in gnome-mount, although I'm using optical media, and not USB storage.

Thanks!

[Marco (marco-redhat-bugs)]

Description of problem:
cryptsetup fail on CDs/DVDs encrypted with LUKS. This causes the Gnome desktop
not to deal properly with them.

Version-Release number of selected component (if applicable):
cryptsetup-luks-1.0.3-0.rc2

How reproducible:
Always.

Steps to Reproduce:
1. Insert a CD/DVD encrypted with LUKS (with the Gnome desktop).

Actual results:
Asks for password, but fails to mount. (NOTE: the cleartext dm device is faulty,
that's why the mount fails.)

Expected results:
After asking for the password to unlock the LUKS volume, the cleartext version
should be mounted under /media/something. Even w/o automagic mounting of the
device, the clear text version of the volume should be available for later mounting.

Additional info:
This is a well-known bug, see:
http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2006-March/000213.html
It should be solved already:
http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2006-March/000250.html
AFAICS, all it takes is to rebuild from the new tarball (rc3).

As a workaround, encrypted CDs/DVDs can be accessed by mapping the reader device
to a loop device and having cryptsetup work on the latter.

losetup /dev/loop0 /dev/cdrom
cryptsetup luckOpen /dev/loop0 myvolume
mount /dev/mapper/myvolume /media/myvolume

There's no quick and clean way to fix /usr/share/hal/scripts/hal-luks-* to do
the above, AFAIK.

[Marco (marco-redhat-bugs)]

Created attachment 130664
detect CDs/DVDs in hal-luks-setup

Well I've tried cryptsetup-1.0.3 (release), but does not seem to work yet. The
only way to successfully Open the LUKS volume is to pass the --readonly to
cryptsetup:

cryptsetup luckOpen --readonly /dev/cdrom myvolume

If you don't specify --readonly, cryptsetup keeps asking you for the password
(even if it reports that the key has been successfully unlocked).

As a consequence g-v-m keeps asking for the password as well.

Attacched is a small patch/hack to fix this behaviour. Anyway for some reason I
still have to find the process stops there. The clear text dm device
(luck_crypto_<UUID>) is created, but not mounted nor added as a volume.

In summary, it seems that the upstream cryptsetup package still has issues with
 CDs/DVDs.

[Ari (ari-reads)]

This is in Feisty, with dm-crypt and dm-mod and aes modules loaded.

Attached are the actual scripts I am using.

[Till (till-redhat-bugs)]

(In reply to comment #1)
> Created an attachment (id=130664) [edit]
> detect CDs/DVDs in hal-luks-setup

> Attacched is a small patch/hack to fix this behaviour. Anyway for some reason I
> still have to find the process stops there. The clear text dm device
> (luck_crypto_<UUID>) is created, but not mounted nor added as a volume.
>
> In summary, it seems that the upstream cryptsetup package still has issues with
> CDs/DVDs.

hal-luks-setup is part of the hal package and when the clear text dm device is
created with above patch, imho it is not a bug in cryptsetup, because it did its
work, but maybe in gnome or in hal. I change this bug to hal, because at least
your patch regards hal. Can you test, whether it works with gnome and your patch
in F7, please?

[Marco (marco-redhat-bugs)]

Well, it's hard to place the blame here. cryptsetup has issues, it keeps failing
when you try to open a luks volume that is on readonly media (CD/DVD). It should
at least detect the problem, and not keep asking the user for a password. I'd
say that the unlock routine keeps failing, but the program doen't really handle
the failure right. The message is even deceiving:

# cryptsetup luksOpen /dev/scd0 myvolume
Enter LUKS passphrase:
key slot 0 unlocked.
Enter LUKS passphrase:
key slot 0 unlocked.
Enter LUKS passphrase:
key slot 0 unlocked.
Command failed: device-mapper: reload ioctl failed: Invalid argument

Please note that I kept typing the right password (it does work, says key slot0
unlocked, but something fails later and it restarts asking the password).

As a WORKAROUND to this cryptsetup 'bug', I tried and patched the hal script.
With --readonly cryptsetup works for cd/dvd. Whether this patch should be in
it's hard call, depends on how the bug is fixed... if cryptsetup recognizes the
readonly media and assumes --readonly, this patch will be totally useless. If
cryptsetup just fails sensibly ("error: media is not writable, please use
--readonly"), then this little patch will be necessary.

Anyway, I should stress it's not enough. I don't understand much on the
internals of the mount mechanics under gnome/nautilus/hal. Even with my patch,
the volume won't be mounted. Only, a dm device appears in this form:

/dev/mapper/luks_crypto_bd6949c6-a617-4bb0-b3b0-723df33f9023

which is just what I think the script I patched is supposed to provide. What I'm
missing, it's why it stops there, and does not mount it. I don't see any
difference with a USB stick with a luks volume (which I think works just fine).

The device file is a working iso9660 image, which I can manually mount. It has a
volume name even:
# iso-info -f /dev/mapper/luks_crypto_bd6949c6-a617-4bb0-b3b0-723df33f9023
iso-info version 0.77 x86_64-redhat-linux-gnu
Copyright (c) 2003, 2004, 2005 R. Bernstein
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
__________________________________
ISO 9660 image: /dev/mapper/luks_crypto_bd6949c6-a617-4bb0-b3b0-723df33f9023
Application: GENISOIMAGE ISO 9660/HFS FILESYSTEM CREATOR (C) 1993 E.YOUNGDALE
(C) 1997-2006 J.PEARSON/J.SCHILLING (C) 2006-2007 CDRKIT TEAM
System : LINUX
Volume : BCK200706C

Once created the mapper device, I'd expect it to be either mounted under /media
(/media/BCK200706C) or at least be visible via nautilus, but it's not. So the
mount process stops somewhere, but I have no idea of where!

BTW, all this has just been tried on a Fedora 7. There's a small obvious
difference in the patch.

[Marco (marco-redhat-bugs)]

Created attachment 160228
patch for hal-luks-setup-linux

Slightly different version of the patch, for Fedora 7. This one applies to
/usr/lib64/hal/scripts/linux/hal-luks-setup-linux, on x86_64.

[Marco (marco-redhat-bugs)]

Created attachment 160229
patch for hal-luks-setup-linux

Opps sorry, the previous one had some extra debugging commands, here's the
clean one.

[Till (till-redhat-bugs)]

I have written a patch that makes cryptsetup "detect" read-only devices. I am
not sure, whether this is really sane or if there is another way to do this in a
better way. It only makes in unnecessary to provide "--readonly" when opening a
cdrom device, so it does not solve this problem completely:
http://cvs.fedoraproject.org/viewcvs/*checkout*/rpms/cryptsetup-luks/devel/cryptsetup-1.0.5-readonly_detection.patch?rev=1.1&only_with_tag=HEAD

[Martin Pitt (pitti)]

Can you please try this with current Hardy? (or gutsy) and check whether it is still an issue?

[Dimas (dimasmjunior)]

I'm not using the script but I am using same procedure to burn encrypted media (CD-R and DVD-R).
The same thing happens: gnome prompts-me for a password; after I provide the correct password it gives-me the error dialog:

"Unable to set up crypto device

Error org.freedesktop.Hal.Device.Volume.Crypto.SetupPasswordError

Error setting up /dev/scd0 - bad password?"

Clicking close brings the password dialog again.
After closing the dialog I can mount it manually without problems.

I'm using Ubuntu Desktop 7.10 (Gutsy), all patches applied.

[Dimas (dimasmjunior)]

I followed the guides in https://wiki.ubuntu.com/DebuggingHal and https://wiki.ubuntu.com/DebuggingRemovableDevices, and I'm posting the logs.

[Bug (bug-redhat-bugs)]

Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

[Marco (marco-redhat-bugs)]

This bug is confirmed in F7 (as stated before).

Confirmed on F8 as well.

Mounting the volume with shell commands works fine:

# cryptsetup luksOpen -r /dev/dvd myvol
# mount -r /dev/mapper/myvol /mnt

After doing some more tests, I discovered this:

USB memsticks work, but only if they carry a partition table. That is, assuming
/dev/sda is your USB sticks device, if /dev/sda1 is your LUKS volume everything
works fine. The LUKS volume is detected, it asks for a passwork, it unlocks it
and mounts it under /media/<volname>.

But if you LUKS format /dev/sda (the disk as a whole) it doesn't. The symptoms
are the same as for CD/DVDs (which of course don't carry a partition table). It
asks for a password, correctly opens the device, but stops before mounting it,
with no errors.

I hope it helps somehow. I don't know where to look for further info.

[John (john-redhat-bugs)]

thanks for the update

[Matthias (matthias-redhat-bugs)]

> I hope it helps somehow. I don't know where to look for further info.

It would be really good to know how well this works on F9, since there have been
quite a few changes in this area.

[Alexander Krivács Schrøder (alexschrod)]

I have used the same method, and I am experiencing the exact same issue as Dimas. ( https://bugs.launchpad.net/ubuntu/+source/gnome-mount/+bug/122241/comments/3 )

[John (john-redhat-bugs)]

Hi Marco,

If possible could you try one more time on Fedora 9 (rawhide)?

Thanks

[Marco (marco-redhat-bugs)]

Sorry, unfortunately I don't have access to a test system right now. I'll have
to ask a friend to do that, I'll let you know.

A couple of questions: is there a Live image of rawhide that I can use for the
test? Is it possible to run a Live image (w/o installing it) of Fedora 9 Preview
and update it to rawhide with yum? Would that make sense? (that is: does it need
a reboot to test the changes? if so, it wouldn't make any sense to try that).

Anyway, the test procedure is quite simple. Maybe someone else will be able to
test it.

Build a LUKS image, even on file:

# dd if=/dev/zero of=luks.img bs=1024k count=10
# losetup /dev/loop0 luks.img
# echo "test" | cryptsetup --batch-mode luksFormat /dev/loop0
Command successful.
# echo "test" | cryptsetup luksOpen /dev/loop0 test
key slot 0 unlocked.
Command successful.
# mke2fs -q -Ltest /dev/mapper/test
# cryptsetup luksClose test
# losetup -d /dev/loop0

Now luks.img holds a 10MB encrypted (although empty) ext2 fs. If you have a
spare USB key, one you can completely wipe out, just first put the image into
the first partition:

(assuming /dev/sda is the USB storage device)
warning: this destroyes the contents of the key
# dd if=luks.img of=/dev/sda1

And just try inserting the key. It should ask for the LUKS password, and after
you type it in ('test'), it should mount (hopefully under /media/test). Umount it.

Now, put the same image on the whole USB device, not the first partition:
# dd if=luks.img of=/dev/sda

When you insert the key, you get the usual password requester, but it won't
mount it correctly. If it does, the bug is solved. :)

You'll have to repartition your USB key, tho.

[Dimas (dimasmjunior)]

I'm now using Ubuntu Desktop 8.04 (Hardy), upgraded from 7.10 (Gutsy). It's still not working: gnome prompts for the password, and after I supply it, gives me the error "Unable to set up crypto device".

Following the guides I mentioned in my last post resulted in the attached logs.

[Mike (mike-redhat-bugs)]

Tested in F9 fully updated as at 7th August 2008.
DMCRYPT-LUKS encrypted CD placed in CDROM - dialogue pops up asking for Luks passphrase.
No further response. No messages in /var/log/messages. No file opened in /media/

I can certainly make the CD contents visible by doing the following steps:
MAPPER="cryptocd"
CDROM=/dev/cdrom
MOUNTDIR=/mnt/tmp
LOOP=$(losetup -f)
losetup $LOOP $CDROM && echo $LOOP >/tmp/loop_device
cryptsetup luksOpen $LOOP $MAPPER
mount /dev/mapper/$MAPPER $MOUNTDIR

Entering the luks passphrase when prompted - then
ls /mnt/tmp
will list the files on the encrypted CD....(Note /mnt/tmp was already defined as a mount point.

[Till (till-redhat-bugs)]

(In reply to comment #13)

> I can certainly make the CD contents visible by doing the following steps:
> MAPPER="cryptocd"
> CDROM=/dev/cdrom
> MOUNTDIR=/mnt/tmp
> LOOP=$(losetup -f)
> losetup $LOOP $CDROM && echo $LOOP >/tmp/loop_device
> cryptsetup luksOpen $LOOP $MAPPER
> mount /dev/mapper/$MAPPER $MOUNTDIR

This will not help to resolve the original problem, but you should not need to use losetup here I guess. And you can probably use mount.crypt from pam_mount to easily mount your cdrom with:

mount.crypt /dev/cdrom /mnt/tmp

umount.crypt /mnt/tmp should also work then.

[Ari (ari-reads)]

Just discovered that the redhat folks also have a bug entry on the very same topic, and have been trying to patch hal... but apparently without success so far

https://bugzilla.redhat.com/show_bug.cgi?id=194249

[Dimas (dimasmjunior)]

Given the fact that multiple users confirmed this, even in other distros, and that all requested information was provided, I'm changing the status from Incomplete to Confirmed.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 8 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Mike (mike-redhat-bugs)]

Tested in F10

The mount works as per #13, but the suggestion from #14 does not as the command line does not recognise mount.crypt

The file browser in gnome sees the encrypted volume and clicking it requests a passphrase but then fails to mount anything. Places in gnome again sees the encrypted drive and requests a passphrase but again fails to mount saying there is no mount point specified.

There are no messages in /var/log/messages indicating any connection to the mount for the CDROM.

This needs to be remedied for F10/F11

[Mike (mike-redhat-bugs)]

Please can this be re-assigned to F10?

[Till (till-redhat-bugs)]

(In reply to comment #16)

> The mount works as per #13, but the suggestion from #14 does not as the command
> line does not recognise mount.crypt

You need to install pam_mount to get mount.crypt

[Mike (mike-redhat-bugs)]

Ahh OK - with pam_mount installed then mount.crypt and umount.crypt do work as per #14 - however I get a request for the passphrase when the CD is loaded into the drive and again another request for the passphrase when I issue the mount.crypt command.

Also going to the device list in the "computer" gui browser, and right clicking to eject the disk fails, but doing "eject /dev/cdrom" in the CLI does work.

It would be nice if this could be cleaned up so it works in a smoother fashion.

I know I could make a small script to mount and umount/eject but it would be nice to have this available by default, and it would also be nice to have this work such that on loading the CD, that the passphrase is requested, then at the same time a mount point entered so that the pam_mount is then executed "under the hood" - or is this a difficult facility to get working? I guess it would fail if an inappropriate mount point was specified but there could be a default such as /media/cdrom_crypt or somesuch?

[Martin (martin-redhat-bugs)]

I myself had this problem and haven't paid attention until I saw this bug report referred from bug#122241 in bugs.launchpad.net (https://bugs.launchpad.net/bugs/122241) recently.

Here is my result in Fedora 11:

1. Insert DVD
2. gnome-mount asks for passphrase; enter one
3. DVD volume appears in the desktop (yeah!)
4. Double-click to open it
5. nautilus launches, the icon disappears from desktop, and the icon is shown in nautilus
6. clicking the icon from nautilus asks for passphrase again, then complains that it's already given the passphrase, but nothing is mounted in /media.
7. 'mount /dev/mapper/devkit-disks/luks-* /mnt/cdrom' from command line works
8. umount and eject works from command line
9. ejecting from nautilus gets complaint that /dev/sr0 is busy used by another module, and eject fails.
10. Subsequent insertion of dvd gets request for passphrase but complains about /dev/sr0 busy. Nautilus shows the icon but no desktop icon. Eject gives the same complaint as above with failure.
11. command line mount/umount/eject all still works.

For now, that's the workaround: Insert dvd, enter passphrase, then simply mount, umount, and eject from command line.

[Martin (martin-redhat-bugs)]

I guess I spoke too soon. Here are more details:

Fedora 11:

1. Insert DVD, enter passphrase when requested
2. icon of the unencrypted volume appears in the desktop, but it disappears as nautilus is launched, and nautilus shows the encrypted volume icon
3. Mount and umount from command line works
4. eject from nautilus works, as long as I don't do eject from command line

So the workaround is:

Insert dvd, enter passphrase;
mount and umount from command line;
eject from gnome/nautilus.

Subsequent closing of DVD drive causes button press eject to not work. The only way to eject is command line eject. once this is done, re-inserting DVD causes the same problem as before: asks for passphrase, then complains that org.freedesktop.DeviceKit.Disks.Error.Busy: One or more block devices are holding /dev/sr0. The same error when trying to eject from nautilus, until the next reboot.

But mount/umount/eject from command line works as usual.

[Riumin (riumin-redhat-bugs)]

I have the same problem - icon appears and immediately disappears in the desktop. After this the same error occured.

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Martin (martin-redhat-bugs)]

As of the latest update of Fedora 11 (11/17/2009), I find that the mounting problem is solved. I can enter the passphrase and access everything from nautilus.

Now I have a different problem. When I eject the drive from GUI right-click, I get the following error, although the disk icon disappears:

Unable to unmount DISK
DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

If I manually eject the dvd, it comes out, but after closing the tray, I cannot open the tray anymore, either from command line or pushing a button. I can see that kcryptd is still running and /dev/mapper/devkit-* still exists, possibly locking the dvd device, which is why I couldn't open the tray.

The only solution is to 'cryptsetup luksClose devkit-*' from command line.

But this causes another problem. If I subsequently insert the same dvd and enter the passphrase, the following error occurs:

The folder contents could not be displayed.
'userdisk' could not be found. Perhaps it has recently been deleted.

I'm not sure I should open a new ticket (since the original problem has been solved) or let someone (original poster) move this to Fedora 11.

[Bug (bug-redhat-bugs)]

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Alasdair (alasdair-redhat-bugs)]

Ref comment #24 - please open a new bugzilla.

[Phillip Susi (psusi)]

This package has been removed from Ubuntu. Closing all related bugs.