[Bug 474327] Re: Overwrite/destroy not-empty partition due to lack of vol_id from udev

Mon Feb 8 17:41:42 GMT 2010

** Description changed:

  Binary package hint: cryptsetup
+ 
+ SRU update rationale:
+ 1. impact of the bug on users:
+ Bugs which may, under realistic circumstances, directly cause a loss of user data.
+ Bug can destroy entire partition on user system while booting, if the user change hard drivers order.
+ 
+ 2. how the bug has been addressed
+ In Lucid we are using blk_id, which works.
+ 
+ 3. A minimal patch applicable to the stable version
+ the one-liner patch is attached
+ 
+ 4. Detailed instructions how to reproduce the bug
+ Was described below by the reporter
+ 
+ 5. A discussion of the regression potential of the patch
+ Very unlikely IMHO.
+ It just stops overwriting existing partition and using it to create without a question encrypted swap
+ 
+ ----

  /lib/cryptsetup/checks/{un_,}vol_id are supposed to check for a type of
  file system on a disk volume. Functions from
  /lib/cryptsetup/cryptdisks.functions use those checks to determine
  whether it is safe to destroy the contents of a volume by e.g calling
  luks create on it:

-     PRECHECK="/lib/cryptsetup/checks/un_vol_id"
+     PRECHECK="/lib/cryptsetup/checks/un_vol_id"

-     [...]
+     [...]

-        if ! pre_out=$("$PRECHECK" "$src" 2> /dev/null) && \
-            [ "$MAKESWAP" != "yes" ] && \
-            ! /lib/cryptsetup/checks/vol_id "$src" swap >/dev/null; then
-                 log_warning_msg "$dst: the precheck for '$src' failed: $pre_out"
-                 return 1
-         fi
+        if ! pre_out=$("$PRECHECK" "$src" 2> /dev/null) && \
+            [ "$MAKESWAP" != "yes" ] && \
+            ! /lib/cryptsetup/checks/vol_id "$src" swap >/dev/null; then
+                 log_warning_msg "$dst: the precheck for '$src' failed: $pre_out"
+                 return 1
+         fi

-     [...]
+     [...]

-      cryptsetup $PARAMS create "$dst" "$src"
+      cryptsetup $PARAMS create "$dst" "$src"

  /lib/cryptsetup/checks/{un_,}vol_id rely on /lib/udev/vol_id from the
  udev package. In Karmic, vol_id it is no longer present. Most
  unfortunately, in this case the checks *pass* with mere warning:

  if test ! -x "/lib/udev/vol_id"; then
-   echo " - WARNING: vol_id from udev is not available, impossible to run checks."
-   exit 0
+   echo " - WARNING: vol_id from udev is not available, impossible to run checks."
+   exit 0
  fi

  I would argue that exit 0 should be exit 1 instead, otherwise it can
  lead to silent data corruption in case the disks connected to the
  machine change. Here is how it happend to me:

  I installed Karmic on HDD1; at that time it was the only drive in the
  box, and thus it was detected as sda. The installer created this entry
  in /etc/crypttab:

  cryptswap1 /dev/sda3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

  After that, I connected my second drive, HDD2, to the box. It happend to
  be connected to the first port of the SATA controller, so when I booted
  off HDD1, hard drive were detected as follows: HDD2: sda, HDD1: sdb. As
  a result, my ext3 partition on HDD2 ("new" sda3) became corrupted
  because of missing vol_id in udev and this bug.

  It looks like the move from vol_id to blkid from util-linux is uderway;
  Debian already has /mnt/lib/cryptsetup/checks/blkid, but the same
  problem is present there too:

  if test ! -x "/sbin/blkid"; then
-   echo " - WARNING: blkid from util-linux is not available, impossible to run checks."
-   exit 0
+   echo " - WARNING: blkid from util-linux is not available, impossible to run checks."
+   exit 0
  fi

  which means data corruption if blkid is missing and your disks changed
  since the time /etc/crypttab was created.

** Description changed:

  Binary package hint: cryptsetup

  SRU update rationale:
  1. impact of the bug on users:
  Bugs which may, under realistic circumstances, directly cause a loss of user data.
  Bug can destroy entire partition on user system while booting, if the user change hard drivers order.

  2. how the bug has been addressed
  In Lucid we are using blk_id, which works.
+ In Karmic the solution is different - the attached patch makes no_vol_id return failure instead of success if vol_id program is missing, therefore it will stop the overwrite of user partition.

  3. A minimal patch applicable to the stable version
  the one-liner patch is attached

  4. Detailed instructions how to reproduce the bug
  Was described below by the reporter

  5. A discussion of the regression potential of the patch
  Very unlikely IMHO.
  It just stops overwriting existing partition and using it to create without a question encrypted swap

  ----