encrypted swap device not correctly configured on fresh raring install

Bug #1172014 reported by James Page on 2013-04-23
This bug affects 4 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Dustin Kirkland 

Bug Description

Fresh Ubuntu Raring install from USB media; home directory configured as encrypted.

On reboot, no swap; /etc/crypttab contained configuration for /dev/sdb3 instead of /dev/sda3; updating and rebooting resolved this issue.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: cryptsetup 2:1.4.3-4ubuntu2
ProcVersionSignature: Ubuntu 3.8.0-19.29-generic 3.8.8
Uname: Linux 3.8.0-19-generic x86_64
ApportVersion: 2.9.2-0ubuntu8
Architecture: amd64
Date: Tue Apr 23 21:43:35 2013
InstallationDate: Installed on 2013-04-23 (0 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423)
MarkForUpload: True
SourcePackage: cryptsetup
UpgradeStatus: No upgrade log present (probably fresh install)
crypttab: cryptswap1 /dev/sda3 /dev/urandom swap,cipher=aes-cbc-essiv:sha256

James Page (james-page) wrote :
Steve Langasek (vorlon) wrote :

The setup of /etc/crypttab comes from the installer, not from cryptsetup; reassigning.

Dmitrijs, does this issue sound familiar to you?

affects: cryptsetup (Ubuntu) → ubiquity (Ubuntu)
Changed in ubiquity (Ubuntu):
assignee: nobody → Dmitrijs Ledkovs (xnox)
Colin Watson (cjwatson) wrote :

It's meant to write UUIDs.

James, could we please have installer logs for this?

affects: ubiquity (Ubuntu) → partman-crypto (Ubuntu)
Changed in partman-crypto (Ubuntu):
status: New → Incomplete
Colin Watson (cjwatson) wrote :

Wait, swap - I misread. ecryptfs-setup-swap looks up the UUID but doesn't write it out in crypttab. That seems like a bug there.

affects: partman-crypto (Ubuntu) → ecryptfs-utils (Ubuntu)
Colin Watson (cjwatson) wrote :

And in fact it'd need to look up the LUKS UUID anyway in order to write it to crypttab. Compare partman-crypto:

        # Use UUID for LUKS devices
        if cryptsetup isLuks "$source"; then
                local uuid=$(cryptsetup luksUUID "$source")

        # Add entry to crypttab
        echo "$target $source $keyfile $opts" >> /target/etc/crypttab

and ecryptfs-setup-swap:

        info `gettext "Setting up swap:"` "[$swap]"
        uuid=$(blkid -o value -s UUID $swap)
        for target in "UUID=$uuid" $swap; do
                if [ -n "$target" ] && grep -qs "^$target " /etc/fstab; then
                        sed -i "s:^$target :\#$target :" /etc/fstab
                        warn "Commented out your unencrypted swap from /etc/fstab"

        while :; do
                [ -e "/dev/mapper/cryptswap$i" ] || break
        # Add crypttab entry
        echo "cryptswap$i $swap /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab

Changed in ecryptfs-utils (Ubuntu):
importance: Undecided → High
status: Incomplete → Triaged
Colin Watson (cjwatson) wrote :

Assuming my analysis is correct, this is not a regression: it dates back at least to precise.

Dustin Kirkland  (kirkland) wrote :

=== modified file 'src/utils/ecryptfs-setup-swap'
--- src/utils/ecryptfs-setup-swap 2012-04-18 16:11:37 +0000
+++ src/utils/ecryptfs-setup-swap 2013-05-08 18:53:53 +0000
@@ -161,7 +161,7 @@
                [ -e "/dev/mapper/cryptswap$i" ] || break
        # Add crypttab entry
- echo "cryptswap$i $swap /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab
+ echo "cryptswap$i UUID=$uuid /dev/urandom swap,cipher=aes-cbc-essiv:sha256" >> /etc/crypttab

        # Add fstab entry
        echo "/dev/mapper/cryptswap$i none swap sw 0 0" >> /etc/fstab

Changed in ecryptfs-utils (Ubuntu):
assignee: Dmitrijs Ledkovs (xnox) → Dustin Kirkland (kirkland)
status: Triaged → In Progress
Dustin Kirkland  (kirkland) wrote :

Committed revision 776.

Changed in ecryptfs-utils (Ubuntu):
status: In Progress → Fix Committed
Sam (cthufoo) wrote :

Installed Saucy and have same issue

My understanding is that having a random key for the partition resets the UUID to something new on each boot. Making the only available fixes: randomly do without swap, use a password key for swap, or leave swap unencrypted.

Launchpad Janitor (janitor) wrote :
Download full text (3.3 KiB)

This bug was fixed in the package ecryptfs-utils - 104-0ubuntu1

ecryptfs-utils (104-0ubuntu1) trusty; urgency=low

  [ Colin King ]
  * src/libecryptfs/ecryptfs-stat.c, tests/kernel/extend-file-
    random/test.c, tests/kernel/inode-race-stat/test.c,
    - Fixed some 32 bit build warnings
  * src/libecryptfs/decision_graph.c, src/libecryptfs/key_management.c,
    src/libecryptfs/main.c, src/libecryptfs/module_mgr.c, src/utils/io.c,
    src/utils/mount.ecryptfs_private.c, tests/kernel/inotify/test.c,
    tests/kernel/trunc-file/test.c, tests/userspace/wrap-unwrap/test.c:
    - Fixed a pile of minor bugs (memory leaks, unclosed file descriptors,
      etc.) mostly in error paths
  * src/key_mod/ecryptfs_key_mod_passphrase.c, src/libecryptfs/main.c,
    - more Coverity fixes, memory leak, error checking, etc.

  [ Nobuto MURATA ]
  * fix an empty update-notifier window (LP: #1107650)
    - changes made in Rev.758 was incomplete

  [ Tyler Hicks ]
  * doc/manpage/ecryptfs.7:
    - adjust man page text to avoid confusion about whether the interactive
      mount helper takes a capital 'N' for the answer to y/n questions
      (LP: #1130460)
  * src/utils/ecryptfs_rewrap_passphrase.c:
    - Handle errors when interactively reading the new wrapping passphrase
      and the confirmation from stdin. Fixes a segfault (invalid memory read)
      in ecryptfs-rewrap-passphrase if there was an error while reading either
      of these passphrases.
  * configure.ac:
    - Set AM_CPPFLAGS to always include config.h as the first include file.
      Some .c files correctly included config.h before anything else. The
      majority of .c files got this wrong by including it after other header
      files, including it multiple times, or not including it at all.
      Including it in the AM_CPPFLAGS should solve these problems and keep
      future mistakes from happening in new source files.
    - Enable large file support (LFS) through the use of the AC_SYS_LARGEFILE
      autoconf macro. ecryptfs-utils has been well tested with LFS enabled
      because ecryptfs-utils is being built with
      '-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' in Debian-based distros.
      This is mainly needed for some of the in-tree regression tests but
      ecryptfs-utils, in general, should be built with LFS enabled.
  * debian/rules:
    - Don't append '-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64' to the CFLAGS
      now that the upstream build enables LFS
  * tests/userspace/lfs.sh, tests/userspace/lfs/test.c:
    - Add a test to verify that LFS is enabled. This test is run under the
      make check target.
  * tests/kernel/enospc/test.c:
    - Fix test failures on 32 bit architectures due to large file sizes
      overflowing data types

  [ Dustin Kirkland ]
  * src/utils/ecryptfs-setup-swap: LP: #1172014
    - write crypttab entry using UUID
  * src/utils/ecryptfs-recover-private: LP: #1028532
    - error out, if we fail to mount the private data correctly

  [ Colin King and Dustin Kirkland ]
  * configure.ac, src/daemon/main.c, src/libecryptfs/cmd_ln_parser.c,


Changed in ecryptfs-utils (Ubuntu):
status: Fix Committed → Fix Released
Albert Pool (albertpool) wrote :

Using UUID in crypttab brought a regression, known as bug #1303002 and bug #1310058 (there may be more duplicates).

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers