Bug#251425: diskless-image-simple: Dangerous /etc/mtab setup on reboot.

[Ivan Vilata i Balaguer <ivan@selidor.net>]

Package: diskless-image-simple
Version: 0.3.18.0.4
Severity: normal

      Hello, I would like to remark a possible situation that may arise
  when using local filesystems under diskless.  It may cause data loss
  and filesystem corruption.

      On booting the diskless node, the shared default/root image is
  mounted readonly.  Then, the node's private default/IP/etc directory
  is mounted on top of the shared /etc directory, which results in the
  node being able to write its /etc/mtab file.  On reboot, remote
  filesystems are unmounted, then the local ones.

      Let us suppose a modification to the /etc/fstab template has been
  done in order to mount a local filesystem of the node (say /tmp).  On
  boot, filesystems are mounted and they are reflected on the node's
  private /etc/mtab.  However, on reboot remote filesystems are unmounted
  first, so the node's private /etc is unmounted and the shared root and
  its /etc directory becomes visible again (the root directory is
  obviously not unmounted even if remote).  This leaves the local
  filesystems mounted but the shared /etc/mtab visible.  The contents of
  the shared /etc/mtab are not reliable and surely do not contain any
  reference to any local filesystem.  When init.d/umountfs runs, 'mount'
  does not see the local filesystems mounted in the node, and the system
  is rebooted without unmounting them, which may lead to serious data
  loss and filesystem corruption.

      Two solutions come to my mind:
	* Editing the shared image /etc/mtab to include the local
	  mounted filesystems.
	* Making a symbolic link from the shared /etc/mtab to
	  /proc/mounts, the kernel's view of mounted filesystems.

  On both cases, unmounting the private /etc would leave a /etc/mtab
  file with the local mounted partitions.  However, since /proc/mounts
  is generated on the fly by the kernel, the second solution would work
  out of the box.  I have tried it and it does not cause any problems on
  the node (on boot or reboot), and neither it does on the server system
  while chroot()ing to the shared image to do administrative tasks.
  Even mounting /proc in the jail is no problem, since /proc/mounts is
  not writable.  The problem is that chroot()ing into the jail makes
  'mount' unusable until /proc is mounted in it.  However, working in
  tha jail without /proc mounted makes equally no sense.  'mount' is not
  frequently used in such a jail, anyway.

      I know this is a rare case, but the solution could avoid dangerous
  situations and, in any case, the shared image's /etc/mtab makes no
  sense in the state it is left when the shared image is build (neither
  does the corresponding node template, buit it does not matter since it
  is cleared on boot).

  Thanks,
      Ivan

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.24orm
Locale: LANG=ca_ES, LC_CTYPE=ca_ES