Red Hat Bugzilla – Bug 478319
gvfs-hal-volume-manager goofy behavior with certain passwords
Last modified: 2015-03-03 17:33:49 EST
Description of problem:
For some reason I am unable to properly use passwords with LuKs and the automount stuff in Gnome. These passwords contain the the characters '12' in them in that order.
That is.. any passwords will work fine, except ones that have 12 in them. Then I get dbus errors and whatnot popping up on my screen.
I have no idea what is going on, but it seems that somewhere along the line there is a program that is not properly sanitizing input and thinks that '12' is significant in some form.
I get two errors that pop up on my gnome desktop when I plug in a LUKS encrypted USB device and successfully enter the correct password:
First I get:
"Cannot mount Volume"
Then when I press the triangle for the 'Details' I get:
"A unknown error has occured"
The second error dialog doesn't pop-up immediately, but after a second or two:
Unable to mount 2.0 GB Encrypted Data
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.
I think the second error is not related directly to the first. I think it's just to inform you that the communication with hald has timed out and the actual error is very misleading. It's the same dialog that will pop up if you do not enter your password in a timely manner.
The odd thing is that it DOES mount the volume successfully. Not every single time, but most of the time. It seems to perform very badly with SD cards, but with USB Flash drives it seems better behaved.
So it seems to me that somewere between HAL, Dbus, or Gvfs stuff there is something very wrong going on. If HAL or Dbus isn't sanatizing input correctly then it may even be a security issue in a multiuser environment.
But I have no way of knowning which component is goofing up.
Version-Release number of selected component (if applicable):
Plug in a USB drive. Run the various cryptsetup commands to create a LUKS-encrypted volume. Format it ext3. Add a password that contains '12' in it.
Plug in the device and use the '12' password and then witness the odd errors.
Steps to Reproduce:
1. Plug in device. (assuming it's a USB drive that shows up as /dev/sdb with one partition)
2. run cryptsetup commands to setup luks volume:
(use 'taco' as the main passphrase)
[root@sylvester ~]# cryptsetup luksFormat /dev/sdb1
This will overwrite data on /dev/sdb1 irrevocably.
Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:
(using 'taco12' as the second key)
[root@sylvester ~]# cryptsetup luksAddKey /dev/sdb1
Enter any LUKS passphrase:
key slot 0 unlocked.
Enter new passphrase for key slot:
(using 'taco12' as the key to confirm it's working)
[root@sylvester ~]# cryptsetup luksOpen /dev/sdb1 poo
Enter LUKS passphrase for /dev/sdb1:
key slot 1 unlocked.
[root@sylvester ~]# mkfs.ext3 /dev/mapper/poo > /dev/null
mke2fs 1.41.3 (12-Oct-2008)
[root@sylvester ~]# echo $?
3. Remove device and plug it back in while running Gnome desktop.
4. When the 'Unlock Encrypted Data' dialog pops up use the 'taco' passphrase and see that it properly mounts and displays contents of the encrypted volume with no errors.
5. right click the icon on your nautilus desktop representing the encrypted volume and select 'Unmount Volume'
6. Remove the device and plug it back in again. This time use the 'taco12' passphrase.
7. Witness the 'cannot mount volume' errors.
The device gets mounted (sometimes) and you get odd and misleading errors on your desktop. Sometimes you can umount it. Other times you need to become root to umount it.
the icon appears on my desktop and nautilus displays contents of encrypted volume.
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:
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.