Bug#906283: initramfs script expects file system on crypto device

2018-08-17 Thread Marc Haber
On Thu, Aug 16, 2018 at 05:57:43PM +0200, Guilhem Moulin wrote:
> On Thu, 16 Aug 2018 at 16:50:55 +0200, Marc Haber wrote:
> > Severity: normal
> 
> Lowering to ‘wishlist’ since AFAIK it's not the a regression; the check
> is already place in 2:1.4.3-4 (stretch), 2:1.6.6-5 (jessie) and
> 2:1.7.3-4 (wheezy):

Yes, but the new thing is that I am now forced to unlock even the LUKS
devices that are not needed for the actual system to run in the
initramfs since my previous unlocking script stopped working with
cryptsetup 2.0.3.

I'm fine with the wishlist severity though since I migrated unlocking to
systemd units calling a one-liner shell script. Ugly, but working.

> So I'd be in favor of removing that check for device types other than
> ‘plain’, without even introducing a new crypttab(5) option.

Fine with me.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421



Bug#906283: initramfs script expects file system on crypto device

2018-08-16 Thread Guilhem Moulin
Control: severity -1 wishlist

Hi Marc,

On Thu, 16 Aug 2018 at 16:50:55 +0200, Marc Haber wrote:
> Severity: normal

Lowering to ‘wishlist’ since AFAIK it's not the a regression; the check
is already place in 2:1.4.3-4 (stretch), 2:1.6.6-5 (jessie) and
2:1.7.3-4 (wheezy):


https://sources.debian.org/src/cryptsetup/2:1.7.3-4/debian/initramfs/cryptroot-script/#L352

https://sources.debian.org/src/cryptsetup/2:1.6.6-5/debian/initramfs/cryptroot-script/#L344

https://sources.debian.org/src/cryptsetup/2:1.4.3-4/debian/initramfs/cryptroot-script/#L319

> I am not sure how to solve this since the behavior of the new script
> seems in order in most regular cases.

Hmm we want that check for `--type=plain` indeed: unlocking a plain
dm-crypt device with a wrong key will happily succeed and yield a mapped
device full of noise; so the check avoids to inadvertently run `mkfs` or
perform other writes that would erase existing (but invisible due to the
key mismatch) non-volatile data.

However, for `--type=luks` (and I guess other header types for which
cryptsetup(8) can use the metadata to verify whether the passphrase is
correct) that check seems unnecessary.  I mean, if the user forgot to
run `mkfs` / `mkswap` for devices that are required at initramfs stage,
then subsequent scripts in the boot process will fail, and it's not
really the job of our own scripts to prevent that (the boot process
would also fail on plaintext devices with unknown file systems).

So I'd be in favor of removing that check for device types other than
‘plain’, without even introducing a new crypttab(5) option.  On top of
my head, the only thing we would stop protecting against, is if the
header is replaced (with `luksHeaderRestore`) with another one where 1/
the same passphrase can unlock both, and 2/ the master keys differ.  In
that case, if the corresponding crypttab(5) entry has the ‘tmp=’
or ‘swap’ options set, then existing non-volatile data might get lost.
Sounds quite an improbable scenario though.

Or did I miss something, Jonas? :-)

-- 
Guilhem.


signature.asc
Description: PGP signature


Bug#906283: initramfs script expects file system on crypto device

2018-08-16 Thread Marc Haber
Package: cryptsetup-initramfs
Version: 2:2.0.4-2
Severity: normal

Hi,

since I am using a keyscript to unlock my crypto devices, I need to use
the initramfs option on all my crypto devices. That includes the virtual
disks for the virtual machines running on the box. Naturally, those
crypto devices don't contain a file system that is recognized by the
get_fstype function sourced from /usr/share/initramfs-tools/scripts/functions

get_fstype ()
{
local FS FSTYPE FSSIZE RET
FS="${1}"

# blkid has a more complete list of file systems,
# but fstype is more robust
FSTYPE="unknown"
eval $(fstype "${FS}" 2> /dev/null)
if [ "$FSTYPE" = "unknown" ]; then
FSTYPE=$(blkid -o value -s TYPE "${FS}")
fi
RET=$?

if [ -z "${FSTYPE}" ]; then
FSTYPE="unknown"
fi

echo "${FSTYPE}"
return ${RET}
}

[30/5020]mh@fan:~ $ sudo /usr/lib/klibc/bin/fstype /dev/mapper/salida
FSTYPE=unknown
FSSIZE=0
[31/5021]mh@fan:~ $ sudo blkid -o value -s TYPE /dev/mapper/salida
[32/5022]mh@fan:~ $

This, in turn, causes
/usr/share/initramfs-tools/scripts/local-top/cryptroot to wrongly assume
that device unlocking was unsuccessful, removes the unlocked device and
starts over.

I am not sure how to solve this since the behavior of the new script
seems in order in most regular cases. Maybe there should be another
crypttab option like "dont-expect-fs" that disables this sanity check
for insane setups like mine.

Greetings
Marc


-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.17.14-zgws1 root=/dev/mapper/root ro splash 
console=ttyS0,57600n8 quiet

-- /etc/crypttab
# this line to avoid accidental commenting of the root line

#fanbtr /dev/disk/by-id/dm-name-fan-c_fanbtr none 
luks,keyscript=/etc/fan/keyscript_fan_root
root /dev/disk/by-id/dm-name-fan-c_root none 
luks,keyscript=/etc/fan/keyscript_fan_root
#root /dev/disk/by-id/dm-name-fan-c_root none 
luks,keyscript=/etc/fan/keyscript_fan_root
#usr /dev/disk/by-id/dm-name-fan-c_usr none 
luks,keyscript=/etc/fan/keyscript_fan

swap0   /dev/disk/by-id/dm-name-fan-c_swap0 none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
boot/dev/disk/by-id/dm-name-fan-c_boot none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
fanbtr_r/dev/disk/by-id/dm-name-fan_r-c_fanbtr_r none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
kernel64/dev/disk/by-id/dm-name-fan-c_kernel64 none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
kernel32/dev/disk/by-id/dm-name-fan-c_kernel32 none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
kernelhome  /dev/disk/by-id/dm-name-fan-c_kernelhome none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan

salida  /dev/disk/by-id/dm-name-fan-c_salida none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#salida_home/dev/disk/by-id/dm-name-fan-c_salida_home none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#nechayev   /dev/disk/by-id/dm-name-fan-c_nechayev none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#spinturn   /dev/disk/by-id/dm-name-fan-c_spinturn none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#spinturn_home  /dev/disk/by-id/dm-name-fan-c_spinturn_home none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan
#spinturn_mbd   /dev/disk/by-id/dm-name-fan-c_spinturn_mbd none 
luks,initramfs,keyscript=/etc/fan/keyscript_fan

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
tmpfs   /tmptmpfs   defaults0   0
/dev/mapper/root /  ext4 noatime,nodiratime 0   1
#/dev/mapper/fanbtr /  btrfs 
subvol=fan-root,ssd,noatime,nodiratime,clear_cache,enospc_debug,skip_balance 0  
 1
#/dev/mapper/fanbtr /mnt/snapshots/fanbtr btrfs 
subvol=snapshots,ssd,noatime,nodiratime,enospc_debug 0   1
/dev/mapper/fanbtr_r /mnt/snapshots/fanbtr_r btrfs 
subvol=snapshots,noauto,nofail,noatime,nodiratime 0   1
/dev/mapper/fanbtr_r /home/mh/bigstuff btrfs 
subvol=mhbig,nofail,noatime,nodiratime 0   1
/dev/mapper/fanbtr_r /home/mh/noback btrfs 
subvol=mhnoback,nofail,noatime,nodiratime 0   1
/dev/mapper/fanbtr_r /home/mh/music btrfs 
subvol=music,nofail,noatime,nodiratime 0   1
proc/proc   procdefaults0   0
#/dev/mapper/root /  ext4errors=remount-ro 0   1
/dev/mapper/swap0 swap  swapnofail  0   0
/dev/mapper/boot /boot  ext4nofail0   2
#/dev/mapper/usr /usr   ext4defaults0   2
#/dev/mapper/var /var   ext4defaults0   2
#/dev/mapper/home /home  ext4defaults0   2
#/dev/mapper/mhbig /home/mh/bigstuff ext4