[PATCH] hald+LUKS start

[David Zeuthen]

On Tue, 2005-02-15 at 11:38 -0600, W. Michael Petullo wrote:
>Attached you should find a patch that begins to add LUKS support to
>hald.  This should eventually provide an easy means to mount encrypted
>filesystems.  Currently, hald only detects that a disk contains a LUKS
>header and sets some relevant parameters.
>

Nice - one question; when I did the sesame stuff I also made volume_id
export key/value pairs; do you think this is needed? I think at least
that we need volume.crypto.type=='LUKS'.

Anyway, I've committed your patch.

>The next step is to cause hald to issue a request for a passphrase and
>mount the real filesystem.  I wanted to present the work I have done so
>far so that others may provide an azimuth check.
>
>I also have two questions:
>
>1.  Can someone give me a quick rundown of the dbus messages emitted
>when a new device is added to a system?  I would like to look into
>modifying gnome-volume-manager so that when a LUKS device is added,
>gnome-volume-manager prompts the console user for a password.  I assume
>that hald uses dbus to tell gnome-volume-manager the properties of a
>newly added device (to include the device type -- crypto_LUKS in this
>case).  Is this correct?

Right, this sounds correct. You want to hook into src/manager.c, more
specifically the function hal_device_added(). You should then check if
the property volume.fsuage is "crypto" and then bring up your dialog.

Note that g-v-m needs to be ported to use hal HEAD - that mostly require
s/hal_/libhal_/ but also some error handling things and how things are
initialized. I think John Palmieri got a patch but I'm not sure yet.

>2.  What is the status of the interface that David Z. mentioned in his
>"notes on making encrypted filesystems "Just Work(tm)": "requires
>new features in hald to callout a program specified in e.g. the
>/etc/hal/methods.d/Crypto/Setup file"?  Is this feature still planned?
>I did ask about this before, but am wondering if there is anything new.
>

Yeah, this is still planned, I just need to actually sit down and
implement it. This should happen fairly soon though.  The way it will
work is that we provide a device information file that, if
volume.fsuage=="crypto" and volume.crypto.type=="LUKS", merges a
property info.method.Volume.Crypto.Setup="/path/to/luks-setup" as well
as appending the string-list property info.supported_interfaces with the
value "org.freedesktop.Hal.Device.Volume.Crypto".

Something like that, this is not implemented yet [1], but it's a goal to
implement this soon.

David

[1] : the thinking here is that a hal device object carries properties
that describe a) what D-BUS interfaces are supported (e.g. always
org.freedesktop.Hal.Device but sometimes others as well) and b) the
mapping from method name to binary that should be invoked if it's not a
built-in method.

All interfaces needs to be specified in the HAL spec and this also means
we can do syntax checking from within the hal daemon.


_______________________________________________
hal mailing list
hal at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/hal