Bug 478319 - gvfs-hal-volume-manager goofy behavior with certain passwords
gvfs-hal-volume-manager goofy behavior with certain passwords
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gvfs (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Tomáš Bžatek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-27 17:43 EST by Nate
Modified: 2015-03-03 17:33 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 02:25:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nate 2008-12-27 17:43:17 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"
Error org.freedesktop.Hal.Device.UnknownError.

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):
gvfs-1.0.3-4.fc10.i386


How reproducible:

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

WARNING!
========
This will overwrite data on /dev/sdb1 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase:  
Verify passphrase: 
Command successful.


(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: 
Verify passphrase: 
Command successful.


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

(format volume)
[root@sylvester ~]# mkfs.ext3 /dev/mapper/poo > /dev/null
mke2fs 1.41.3 (12-Oct-2008)
[root@sylvester ~]# echo $?
0


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. 

  
Actual results:

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.


Expected results:

the icon appears on my desktop and nautilus displays contents of encrypted volume. 

Additional info:
Comment 1 Bug Zapper 2009-11-18 05:35:21 EST
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
Comment 2 Bug Zapper 2009-12-18 02:25:13 EST
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.

Note You need to log in before you can comment on or make changes to this bug.