[Bug 1780332] Re: vaultlocker does not ensure that udev is triggered to create /dev/disk/by-uuid/<uuid-in-luks-header> symlink and fails
James Page
james.page at ubuntu.com
Fri Sep 14 16:06:22 UTC 2018
Dimitri
vaultlocker is a helper tool for managing dmcrypt/LUKS keys in Vault.
vaultlocker provides commands to format a block devices using an
encryption key, and to unlock a block device previously encrypted by
vaultlocker (along with some systemd unit configurations to perform this
action on reboots).
Currently vaultlocker performs targetted rescan and settle udevadm
operations post luksFormat to wait for appropriate /dev entries to be
created; I consider this a workaround as it would be generally nicer if
this was actually performed as part of the luksFormat operation in
cryptsetup - once the format operation completes, block devices would be
ready for use without any need to udevadm trigger/settle in other
tooling.
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1780332
Title:
vaultlocker does not ensure that udev is triggered to create /dev/disk
/by-uuid/<uuid-in-luks-header> symlink and fails
Status in vaultlocker:
Fix Released
Status in cryptsetup package in Ubuntu:
New
Status in systemd package in Ubuntu:
Incomplete
Bug description:
When an encrypted device is setup up a UUID (osd_fsid) is passed from
the charm to be used in the cryptsetup command which accepts a UUID to
place into the LUKS header (shown in cryptsetup luksDump <path-to-
block-device>).
https://github.com/openstack/charm-ceph-osd/blob/stable/18.05/lib/ceph/utils.py#L1788-L1804
UUID comes from osd_fsid
https://github.com/openstack-charmers/vaultlocker/blob/8c9cb85dc3ed5dbf18c66a810d189a5230d85c34/vaultlocker/shell.py#L69-L80
# else statement is used here
block_uuid = str(uuid.uuid4()) if not args.uuid else args.uuid
dmcrypt.luks_format(key, block_device, block_uuid) # creates a LUKS header
# ...
dmcrypt.luks_open(key, block_uuid) # sets up a device with device mapper decrypting it via dmcrypt
https://github.com/openstack-
charmers/vaultlocker/blob/d813233179bdf2eec8ed101c702a8e552a966f44/vaultlocker/dmcrypt.py#L44-L56
This UUID is visible in blkid output
/dev/sdc: UUID="<luks-header-uuid>" TYPE="crypto_LUKS"
and a udev rule exists to create a /dev/disk/by-uuid/<luks-header-
uuid> symlink (which is normally used for filesystem -> block device
resolution)
https://git.launchpad.net/~usd-import-team/ubuntu/+source/lvm2/tree/udev/13-dm-disk.rules.in#n25
ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*", SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
Where vaultlocker fails is in luks_open command (right after luks_format)
# cryptsetup --batch-mode --key-file - open UUID=<luks-header-uuid>
crypt-<luks-header-uuid> --type luks
because it tries to access /dev/disk/by-uuid/<luks-header-uuid> which
does not exist.
This happens since udev rules are not re-triggered to create this
symlink after a LUKS device is created.
Solution: call the command below after luks_format before luks_open
udevadm settle --exit-if-exists=/dev/disk/by-uuid/<luks-header-uuid-
equal-to-osd-fsid>
To manage notifications about this bug go to:
https://bugs.launchpad.net/vaultlocker/+bug/1780332/+subscriptions
More information about the foundations-bugs
mailing list