Cannot unlock encrypted device: unhandled device about udiskie HOT 9 CLOSED

Hey, thanks for your report.

My first guess is that this might be due to the UDisks2 system-internal heuristic.

Let's investigate:

udiskie-mount -v /dev/sdb2

gdbus call --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/block_devices/sdb2 --method org.freedesktop.DBus.Properties.GetAll org.freedesktop.UDisks2.Block

One of the DEBUG lines near the end of the udiskie output should contain a hint as to why the device was rejected by udiskie.

The gdbus command will show the device properties that were detected by UDisks2.

Until we figure out the problem, you can (hopefully) use the this ad-hoc fix: Create the file .config/udiskie/config.yml with the following contents:

ignore_device:
 - id_uuid: 6A34ADBFF4A47B48
   ignore: false

where you should take the UUID from the IdUUID field of the gdbus command output.

from udiskie.

Before the config option:

udiskie:

$ udiskie-mount -v /dev/sdb2
DEBUG [2015-04-22 13:53:06,834] udiskie.config: MountOptions(match={'id_type': 'ntfs'}, value=['umask=0033']) created
DEBUG [2015-04-22 13:53:06,901] udiskie.config: IgnoreDevice(match={'is_block': False}, value=True) created
DEBUG [2015-04-22 13:53:06,901] udiskie.config: IgnoreDevice(match={'is_external': False}, value=True) created
DEBUG [2015-04-22 13:53:06,901] udiskie.config: IgnoreDevice(match={'is_ignored': True}, value=True) created
DEBUG [2015-04-22 13:53:07,034] udiskie.mount: found device owning "/dev/sdb2": "/org/freedesktop/UDisks2/block_devices/sdb2"
DEBUG [2015-04-22 13:53:07,069] udiskie.config: IgnoreDevice(match={'is_ignored': True}, value=True) used for /org/freedesktop/UDisks2/block_devices/sdb2
WARNING [2015-04-22 13:53:07,069] udiskie.mount: not unlocking /org/freedesktop/UDisks2/block_devices/sdb2: unhandled device

gdbus:

$ gdbus call --system --dest org.freedesktop.UDisks2 --object-path /org/freedesktop/UDisks2/block_devices/sdb2 --method org.freedesktop.DBus.Properties.GetAll org.freedesktop.UDisks2.Block
({
  'Device': <b'/dev/sdb2'>,
  'PreferredDevice': <b'/dev/sdb2'>,
  'Symlinks':
    <[
      b'/dev/disk/by-id/usb-Kingston_DataTraveler_2.0_C860008861D7EEC19A1374E8-0:0-part2',
      b'/dev/disk/by-path/pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0-part2',
      b'/dev/disk/by-uuid/ebbd97f7-701f-4d14-b750-0c44c3ca9e5e'
    ]>,
  'DeviceNumber': <uint64 2066>,
  'Id': <'by-id-usb-Kingston_DataTraveler_2.0_C860008861D7EEC19A1374E8-0:0-part2'>,
  'Size': <uint64 1363902464>,
  'ReadOnly': <false>,
  'Drive': <objectpath '/org/freedesktop/UDisks2/drives/Kingston_DataTraveler_2_2e0_C860008861D7EEC19A1374E8'>,
  'MDRaid': <objectpath '/'>,
  'MDRaidMember': <objectpath '/'>,
  'IdUsage': <'crypto'>,
  'IdType': <'crypto_LUKS'>,
  'IdVersion': <'1'>,
  'IdLabel': <''>,
  'IdUUID': <'ebbd97f7-701f-4d14-b750-0c44c3ca9e5e'>,
  'Configuration':
    <[(
      'crypttab',
      {
        'name': <b'ring'>,
        'device': <b'UUID=ebbd97f7-701f-4d14-b750-0c44c3ca9e5e'>,
        'passphrase-path': <b'/etc/cryptkeys/ring'>,
        'options': <b'noauto'>
      }
    )]>,
  'CryptoBackingDevice': <objectpath '/'>,
  'HintPartitionable': <true>,
  'HintSystem': <false>,
  'HintIgnore': <true>,
  'HintAuto': <true>,
  'HintName': <''>,
  'HintIconName': <''>,
  'HintSymbolicIconName': <''>
},)

After the config entry:

udiskie-mount:

$ udiskie-mount -v /dev/sdb2
DEBUG [2015-04-22 14:06:48,970] udiskie.config: MountOptions(match={'id_type': 'ntfs'}, value=['umask=0033']) created
DEBUG [2015-04-22 14:06:48,970] udiskie.config: IgnoreDevice(match={'id_uuid': 'ebbd97f7-701f-4d14-b750-0c44c3ca9e5e'}, value=False) created
DEBUG [2015-04-22 14:06:49,045] udiskie.config: IgnoreDevice(match={'is_block': False}, value=True) created
DEBUG [2015-04-22 14:06:49,045] udiskie.config: IgnoreDevice(match={'is_external': False}, value=True) created
DEBUG [2015-04-22 14:06:49,045] udiskie.config: IgnoreDevice(match={'is_ignored': True}, value=True) created
DEBUG [2015-04-22 14:06:49,155] udiskie.mount: found device owning "/dev/sdb2": "/org/freedesktop/UDisks2/block_devices/sdb2"
DEBUG [2015-04-22 14:06:49,183] udiskie.config: IgnoreDevice(match={'id_uuid': 'ebbd97f7-701f-4d14-b750-0c44c3ca9e5e'}, value=False) used for /org/freedesktop/UDisks2/block_devices/sdb2
Enter password for /dev/sdb2: 
DEBUG [2015-04-22 14:07:00,215] udiskie.mount: unlocking /org/freedesktop/UDisks2/block_devices/sdb2
ERROR [2015-04-22 14:07:25,247] udiskie.mount: failed to unlock /org/freedesktop/UDisks2/block_devices/sdb2: Timeout was reached

I also tried to unlock the partition by using cryptsetup luksOpen and udisksctl unlock.
The cryptsetup way works as it should (if used as root), but the udisksctl unlock freezes after
the password is entered.

EDIT: I should also mention, that the encrypted partition has two keys in its crypto table: one is binary file stored on my laptop, the other is plain-text passphrase to be entered when mounting the drive elsewhere than my laptop :) TBH, at first I totally forgot about the binary key, as this is not important for me right now - I will be happy if I can mount the drive after providing the plain-text passphrase.

from udiskie.

Okay.

Original problem: The device has the HintIgnore flag set to true (which was probably intentional, so it doesn't show in your file manager?) and was therefore (IMO) correctly ignored by udiskie. The unignore rule inside the udiskie configuration is a perfectly valid fix for that, I don't think udiskie should be patched in this regard.

Edit: If you don't want the HintIgnore flag to be used for any of your devices, you could overwrite the udiskie default behaviour by adding the following 3 rules to your udiskie-config:

ignore_device:
- is_block: false
- is_external: false
- is_ignored: true
  ignore: false

New problem: the freeze is curious (didn't encounter that problem so far)...

• did you try this with Udisks1 too?
• does this problem only occur on your laptop, or does it also occur on other machines?
• can you reproduce the same problem with a different device?
• maybe you can try to create a minimal example for how to setup a problematic device to see what causes the problem? Otherwise, I could later try to reproduce your problem on my system on my own.
• does it help to remove the key file? (but don't ruin your data!;)
• I will have to think about this a little and come back to you later.

from udiskie.

Okay, as it turns out, the source of the original problem was my own forgetfulness -- I was
fiddling with autofs before and write udev rule to ignore that partition, which I subsequently
forgot to delete (and that it even exists) when I start to work with udiskie.

The freeze occurs only with Udisks2, so it is either misconfiguration or bug within it, and most
probably also not related to udiskie (because it occurs also with udisksctl). If I later find otherwise, I will report back.

Edit: The Udisks2 freeze disappeared when I removed reference to the keyfile from crypttab. I'm guessing it was caused by Udisks2 incorrectly handling multiple LUKS key entries. If you want to try on your device, create LUKS-encrypted partition and add another key (ideally binary file), then add reference to the key file into /etc/crypttab and try to unlock&mount.

So this issue can probably be closed. Sorry for mistargeting the issue and thank you very much for your assistance, helped me a lot.

from udiskie.

You're right, this is most likely a problem inside udisks2. I tried to reproduce the problem anyway and failed:

# as root:
dd if=/dev/urandom of=/home/key count=4 bs=1024
echo "TEMP  /dev/sdb2  /home/key" >> /etc/crypttab

mkfs.ntfs --quick /dev/sdb1
cryptsetup luksFormat /dev/sdb2
cryptsetup luksAddKey /dev/sdb2 /home/key

# now as user
udisksctl unlock -b /dev/sdb2 # works

So there must be more to it.

The problem is not necessarily inside udisks. It could (although unlikely) e.g. also be due to a misbehaving polkit rule that blocks indefinetely.

Can you check out whether the polkit permission is even queried by adding a rule /etc/polkit-1/rules.d/10-udisks.rules.

polkit.addRule(function(action, subject) {
  var prefix = "org.freedesktop.udisks";
  if (action.id.slice(0, prefix.length) == prefix)
    polkit.log(action.id);
});

and then following the log while trying to unlock

journalctl -n 20 -f -u polkit.service

Also, follow the udisks log

journalctl -n 20 -f -u udisks2.service

I apologize if this issue is done for you and you don't want to be bothered anymore;)

from udiskie.

Ok, I returned the line that caused the issue into crypttab, and add the polkit logging.

For reference, this is the crypttab line:

ring UUID=ebbd97f7-701f-4d14-b750-0c44c3ca9e5e /path/to/key

Then I setup the log commands, and run udisksctl unlock -b /dev/sdb2.
The udisks2 logged nothing (the log did not chage during the execution).
The polkit log showed only one line, right after asking for passphrase (which means it probably
does not use the crypttab entry):

polkitd[1000]: /etc/polkit-1/rules.d/10-udisks.rules:4: org.freedesktop.udisks2.encrypted-unlock

So the rule is queried, but right after that, the freeze occurs -- I waited few minutes and then
kill it with SIGKILL.

Then I tried with udiskie-{umount,mount} -a, and got timed out again.

P.S.: No need to apologize, happy to help :)

from udiskie.

Hey,

With your crypttab line, I could reproduce the problem. I have tracked it down to this point:

Running udisksctl unlock will call handle_encrypted (in udiskslinuxencrypted.c). This in turn tries to execute a cryptsetup command by calling udisks_daemon_launch_spawned_job_sync (udisksdaemon.c). Here is where things go sour. The synchronous launch function enters but never exits from its mainloop.

In my example udisks_daemon_launch_spawned_job_sync tries to execute the following command:

cryptsetup luksOpen "/dev/sdb1" "ring"

If I run the same command in my root terminal, I get asked to enter a password. So, I guess the reason that the job never finishes might be that there is no appropriate terminal to enter a password into.

So, at this point, I have to admit that I don't know enough about the whole cryptsetup/luks/crypttab/udisks2 stuff to determine who is responsible and what should be changed. Maybe you can turn to the udisks2 devs with this information?

Best regards,
Thomas

from udiskie.

I have already started writing a bug report when I read your response :) As this manifested on Fedora 21, I have reported it to Fedora bugzilla. In case you want to follow, here is the link: https://bugzilla.redhat.com/show_bug.cgi?id=1214756.

Best regards and thanks for wonderful cooperation,
Jan

from udiskie.

FYI, I posted this on the udisks bug tracker (I think that's a better location)

https://bugs.freedesktop.org/show_bug.cgi?id=90173

BTW: I also discovered that the freeze disappears if you insert an additional space in between the first two columns in your crypttab entry (but you will still be asked for a password).

from udiskie.