Bug 194249

Created attachment 130664 [details]
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.

(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?

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.

Created attachment 160228 [details]
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.

Created attachment 160229 [details]
patch for hal-luks-setup-linux

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

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

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

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.

thanks for the update

> 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.

Hi Marco,

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

Thanks

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.

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.

(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.

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

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

Please can this be re-assigned to F10?

(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

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?

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.

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.

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

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

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.

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.

Ref comment #24 - please open a new bugzilla.