De-duplicated this bug, affected to "mountall", updated description.

The interaction issue between mountall and cryptsetup has been described
in detail in bug #475936 and some cryptsetup fixes have been attempted,
that don't fix the race condition with mountall.

mountall logs are available in comments 19 and 20 of bug #475936

** Description changed:

- Binary package hint: upstart
+ Binary package hint: Mountall
  
- Hi,
+ (Swâmi Petaramesh 2009/12/21: De-duplicating this bug and affecting it
+ to the mountall package per Steve Langasek suggestion in #475936 comment
+ 12)
  
- I've seen this discussed (with no solution) in several forums posts, and
- I've seen some "about similar" bug reports, but not the exact same, or
- marked "incomplete", so I file this one as I believe this is a high
- priority and security issue.
+ mountall doesn't wait for cryptsetup to finish setting up encrypted temporary 
filesystems (/tmp) and fails mounting them.
+ It sometimes affects encrypted swap as well.
+ 
+ The result is that the system boots with encrypted /tmp not mounted, and 
temporary files go unencrypted in the /tmp directory of the root filesystem.
+ Also, the system may have no swap after bootup.
+ 
+ ----
  
  - After upgrade from Intrepid to Karmic, encrypted /tmp and encrypted
  swap defined in /etc/crypttab do not work any longer, where they worked
  perfectly before.
  
  /etc/crypttab entries are i.e.:
  c_swap         /dev/mapper/VG1-c_swap  /dev/urandom    size=128,swap
  c_tmp           /dev/mapper/VG1-c_tmp   /dev/urandom    size=128,tmp
  
  /etc/fstab entries are i.e.:
  /dev/mapper/c_tmp /tmp ext2 relatime,nosuid 0 0
  /dev/mapper/c_swap none swap sw 0 0
  
  Symptoms are :
  - During boot, cryptsetup always properly creates and formats the encrypted 
c_tmp and c_swap volumes with random keys - so that's no cryptsetup issue.
  
  The rest of the system behaviour is not always consequent :
  1/ The encrypted swap is sometimes properly "swapon'ed", and sometimes not.
  
  2/ The encrypted /tmp is NEVER auto-mounted although it has been
  properly created and formatted
  
  3/ The startup scripts always spit a message stating that "not all the
  partitions defined in fstab could be mounted"
  
  4/ The boot process *sometimes* hangs with a "Type root password or
  CTRL-D to continue", and sometimes not.
  
  5/ When the system finishes booting, typing "mount -a" gets the
  encrypted /tmp properly mounted.
  
  (It's worth noticing that I also have an encrypted /home using a
  permanent key, and this one still works flawlessly...?!?)
  
  It appears to me that the startup scripts are doing things
  asynchronously or in the wrong order for encrypted filesystems, and
  that's a major issue.
  
  The system running with /tmp not mounted, thus potentially sensitive
  /tmp data stored unencrypted in the root filesystem, I mark this as a
  security issue.

-- 
[Karmic, security] Encrypted partitions no longer mounting after upgrade to 
karmic
https://bugs.launchpad.net/bugs/493480
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to