Patch to auto-mount LUKS key-file encrypted volumes

Bug #133520 reported by TJ on 2007-08-19
26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
gnome-mount
Won't Fix
Wishlist
gnome-mount (Baltix)
Undecided
Unassigned
gnome-mount (Ubuntu)
Low
Unassigned
hal (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: hal

Feisty + Gnome, gnome-mount

With a LUKS encrypted volume on an external device, when the device is connected gnome-volume-manager calls gnome-mount which prompts for the encrypted volume password.

If the volume is *only* protected by a key-file gnome-mount fails and "sudo cryptsetup luksOpen /dev name --key-file file.key" is needed to be run manually.

As a first step to providing full support for key-files I have modified the hal script:

/usr/lib/hal/scripts/linux/hal-luks-setup-linux

I am working on a modification to gnome-mount too, so it won't prompt for a password if a valid key-file is available.

Once the patched script is installed, when plugging in a LUKS encrypted volume gnome-mount will *still* ask you for a password but you can type in anything (it will be ignored) and press Enter. gnome-mount will execute the hal script which will check for a key-file and use it if found.
If there is no matching key-file the script will show an error-dialog reporting "bad key-file?" and then ask for a password as before. This gives a chance to insert the key-file device (I have it on a USB flash key).

If you save the password you typed either for the session, or forever, you won't get the password prompt again unless the key-file isn't found.

I've added functionality at the start of the script to check /etc/crypttab and match it against the argument passed to gnome-mount by gnome-volume-manager, e.g:

     --hal-udi=/org/freedesktop/Hal/devices/volume_uuid_408e7dbc-1cad-4eff-9a06-1b1f9f60d22a

The entry in /etc/crypttab *must* use the UUID in the device column, like this, for the script to work:

# <target name> <source device> <key file> <options>
mobile120 /dev/disk/by-uuid/408e7dbc-1cad-4eff-9a06-1b1f9f60d22a /media/key3/disk.key luks

The script will match the UUID, get the device name and the key-file, and call cryptsetup luksOpen.

----- /usr/lib/hal/scripts/linux/hal-luks-setup-linux -----------------

#!/bin/bash

# Copyright (C) 2005 W. Michael Petullo <email address hidden>
# Copyright (C) 2006 David Zeuthen <email address hidden>
# Copyright (C) 2007 TJ <email address hidden>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License version 2.

CRYPTSETUP=/sbin/cryptsetup

# detect key-file protected volume
LUKS="`grep \"${HAL_PROP_VOLUME_UUID#*_uuid_}\" /etc/crypttab`"
MAPPER="`echo $LUKS | awk '{print $1}'`"
DEVICE="`echo $LUKS | awk '{print $2}'`"
KEYFILE="`echo $LUKS | awk '{print $3}'`"

# if there is a key-file, attempt to open the LUKS device with it
if [ "x${KEYFILE}" != "x" ]; then
   if ! $CRYPTSETUP luksOpen $DEVICE luks_crypto_$HAL_PROP_VOLUME_UUID --key-file $KEYFILE 2> /dev/null; then
    echo org.freedesktop.Hal.Device.Volume.Crypto.SetupPasswordError >&2
    echo "Error setting up $HAL_PROP_BLOCK_DEVICE - bad key-file?" >&2
    exit 1
   fi
else

read PASSWORD

if [ ! -f $CRYPTSETUP ]; then
    echo org.freedesktop.Hal.Device.Volume.Crypto.CryptSetupMissing >&2
    echo Error setting up $HAL_PROP_BLOCK_DEVICE - $CRYPTSETUP not found >&2
    exit 1
fi

if [ -e /dev/mapper/luks_crypto_$HAL_PROP_VOLUME_UUID ]; then
    echo org.freedesktop.Hal.Device.Volume.Crypto.SetupError >&2
    echo $HAL_PROP_BLOCK_DEVICE is already setup? >&2
    exit 1
fi

if ! echo "$PASSWORD" | $CRYPTSETUP luksOpen $HAL_PROP_BLOCK_DEVICE luks_crypto_$HAL_PROP_VOLUME_UUID 2> /dev/null; then
    echo org.freedesktop.Hal.Device.Volume.Crypto.SetupPasswordError >&2
    echo Error setting up $HAL_PROP_BLOCK_DEVICE - bad password? >&2
    exit 1
fi

fi

hal-set-property --udi=$UDI --key="info.callouts.remove" --strlist-pre="hal-luks-remove" > /dev/null 2>&1

exit 0

TJ (tj) wrote :

Accidentally got the default selection of Baltix in error - please remove this Distro from the bug

Changed in gnome-mount:
assignee: nobody → intuitive-nipple
status: New → Fix Committed
Changed in hal:
assignee: nobody → intuitive-nipple
status: New → Fix Committed
Changed in gnome-mount:
status: New → Invalid
TJ (tj) on 2007-08-19
description: updated
TJ (tj) on 2007-08-19
description: updated
TJ (tj) on 2007-08-19
description: updated
TJ (tj) on 2007-08-19
description: updated
TJ (tj) on 2007-08-19
description: updated
TJ (tj) on 2007-08-19
description: updated
TJ (tj) wrote :

This is the patch against the gnome-mount-0.5 package (src/Makefile.am and src/gnome-mount.src)

A new compile flag CRYPTO_KEYFILE is defined to enable the keyfile support.

Changed in gnome-mount:
status: Unknown → New
TJ (tj) on 2007-08-20
description: updated
TJ (tj) on 2007-09-02
Changed in gnome-mount:
importance: Undecided → Low
Changed in hal:
importance: Undecided → Low
TJ (tj) on 2007-09-22
Changed in gnome-mount:
status: Fix Committed → Confirmed
Changed in hal:
status: Fix Committed → Confirmed
Changed in gnome-mount:
status: Confirmed → Triaged
TJ (tj) wrote :

I've updated the patches required for Hardy and the package(s) are available from my PPA.

I've modified gnome-mount too, so when a key-file exists the password isn't requested. If the key-file isn't available when gnome-mount first looks it will display the usual gnome LUKS password request dialog. At this point insert the device with the LUKS key-file on (the location of the key-file is specified in /etc/crypttab) then without entering a password press the Connect button and the volume will be unlocked and mounted.

https://launchpad.net/~intuitivenipple/+archive

Packages:

hal - 0.5.11~rc2-1ubuntu8.2~ppa1
gnome-mount - 0.8~svn20080225-0ubuntu5~ppa1

Changed in gnome-mount:
assignee: intuitivenipple → nobody
status: Triaged → Fix Released
Changed in hal:
assignee: intuitivenipple → nobody
status: Confirmed → Fix Released
James Blackwell (jblack) wrote :

TJ,

Thanks for making these packages. I hope they get into ubuntu proper some day.

If the fix is NOT in Ubuntu then the status should NOT be set to Fix Released. For more information please see point 2-3 under "Fix Released" on this page: https://wiki.ubuntu.com/Bugs/Status

For information on how to get your fix into Ubuntu please see: https://wiki.ubuntu.com/SponsorshipProcess

Thanks.

Changed in hal:
status: Fix Released → Triaged
Changed in gnome-mount:
status: Fix Released → Triaged
Martijn Vermaat (mvermaat) wrote :

Related to this bug, and also caused by HAL not reading /etc/crypttab, is that automounting encrypted devices does not respect the mapping path in /etc/crypttab.

Based on TJ's modification, I fixed this.

I think both fixes should be combined, so /etc/crypttab is respected by HAL (and thus gnome-mount).

David Futcher (bobbo) on 2010-06-10
tags: added: patch-forwarded-upstream
Changed in gnome-mount:
importance: Unknown → Wishlist
Changed in gnome-mount:
status: New → Won't Fix
dino99 (9d9) wrote :
Changed in hal (Ubuntu):
status: Triaged → Invalid
Changed in gnome-mount (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.