volume.is_mounted wrong for luks partitions

[David Zeuthen]

Hi,

Sorry for the lag,

On Fri, 2006-04-07 at 21:16 +0000, Lars wrote:
> Hi,
> I use a luks encrypted partition that is mounted during boot.

How is this setup and mounted? What piece of software / distro does
this? 

You should know that HAL right now relies on the symlink in /dev/mapper
to be of the form

 /dev/mapper/luks_crypto_557ab7d5-b75e-4f9e-adde-157ff139f9fc

with the LUKS UUID after luks_crypto, because when we wrote this code in
HAL we didn't know of any easy way to get the link from the logical
volume (e.g. /dev/dm-0) to the physical volume (e.g. /dev/sda2). See
below also.

> lshal reports the 'volume.is_mounted' property of the device as 'false' - which
> is wrong.
> 
> For now, the mount-detection of hal simply looks for the device name listed in
> /proc/mounts - right? This is _sadly_ not appropriate for luks encrypted
> devices, as only the /dev/mapper/NAME device is listed in /proc/mounts.

On Fedora Core 5 and Rawhide it's actually /dev/dm-0 etc. that is listed
but this is probably due to the fact that gnome-mount uses this one when
mounting.

> I 'solved' the problem by manually setting the value in my preferences.fdi file,
> but this is surely not a real solution.
> 
> AFAICT hal would need to call the 'dm_task_get_deps' function of libdevmapper to
> find the underlying device, but this sounds not too easy for me (I am not a
> programmer - sorry).

That sounds interesting; something to look into.

> How could this be fixed?

Well, the kernel passes /dev/dm-0 as the hotplug event so I think we
should continue to use this. I suppose we could replace this with the
name

 /dev/mapper/luks_crypto_557ab7d5-b75e-4f9e-adde-157ff139f9fc

since we already check for symlinks anyway. And I feel bad about using a
device file that is not maintained by udev, in fact I'd argue it's a bug
that cryptsetup, dmsetup and friends write their own device files. /dev
on Linux 2.6 is supposed to be managed by udev, and only by udev. But I
suppose I won't win any popularity contests with that point of view :-)

Another thing is that we really want to get away from looking at
symlinks and use e.g. dm_task_get_deps to figure out that the device
mapper volume really stems from the LUKS encrypted physical volume.

I'm not really sure what to do... expect to say that the software that
mounts your LUKS volume at boot needs to be fixed to use /dev/dm-0 etc.
which is the right device file to use, instead of some device file that
is not managed by udev.

Long term, maybe, some udev rule could rewrite /dev/dm-0 etc. to be of
the right form /dev/mapper/NAME and cryptsetup, dmsetup and friends can
stop violating /dev (allowing programs other than udev manage files
in /dev is a security risk). Kay, what do you think?

     David