add support for setting up encrypted home directory on user creation

Note that the majority of the attached patch is internationalization noise. The pertinent changes are:

 adduser | 14 +
 debian/changelog | 10 +
 debian/control | 1
 doc/adduser.8 | 6

Also note that this should not be uploaded until the required ecryptfs-utils package hits the archives. I'll ping here again when that happens.

In the meantime, I'm going to upload both an adduser and an ecryptfs-utils that work together to my PPA.

:-Dustin

Adding a task for ecryptfs-utils, which has the 2nd half of the functionality required.

:-Dustin

Also adding an upstream ecryptfs task, as I will be pushing these changes back upstream to the ecryptfs-utils project.

:-Dustin

Attaching the ecryptfs-utils debdiff patch. I'm uploading to my PPA for integration testing with adduser. Please don't sponsor to Jaunty just yet. I'd like to commit upstream first, and merge into an upcoming ecryptfs-utils-67 release.

:-Dustin

The following two packages are built in my PPA. Please respond here with any bugs/issues:
 * adduser - 3.110ubuntu2~ppa1
 * ecryptfs-utils - 66-2ubuntu4~ppa1

See:
 * https://launchpad.net/~kirkland/+archive

To test, enable my PPA for Jaunty, and upgrade these two packages.

Then, as root, create a new user with:
 # adduser --encrypt-home $user

Fill in the required information, and password accordingly. Login as that user and you should be able to operate as usual, with your entire home directory encrypted.

Note that:
 * your encrypted data will reside in /home/$user/.Private
 * this directory will not be visible while mounted
 * your ecryptfs configuration data, which is required to establish the mount will live in /var/lib/ecryptfs/$user and will be symbolically linked into /home/$user

Enjoy
:-Dustin

I'm adding a task for system-tools-backends, as the graphical "add user" utility should also support this feature.

Reading my process table, it looks to me like this is handled by:
/usr/bin/perl /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UserConfig

:-Dustin

Hmm, actually, it looks like it might be /usr/bin/users-admin provided by gnome-system-tools?

:-Dustin

Marking system-tools-backends invalid. Adding gnome-system-tools. I suppose we need the KDE equivalent as well...

:-Dustin

Attaching an updated adduser debdiff, recommending on the ecryptfs-utils that was uploaded today.

This is ready for upload. Requesting sponsorship...

:-Dustin

Thanks, Dustin.

At the moment it looks like adduser doesn't have a very good failure case handling. What happens if ecryptfs-setup-private doesn't exist (it's only recommended, and this is a good thing)? Or if it fails? IMHO it should make adduser fail gracefully with a proper error message, instead of silently working without an encrypted home dir.

A kind of Christmas wishlist thing is adding an option for this into adduser.conf, so that sysadmins can set it as default and thus every program calling adduser would create an encrypted home directory. What do you think about that? (Not a blocker for upload, of course)

Martin,

I actually tested the absence of ecryptfs-setup-private... It's sort of handled by:
  my $ecryptfs_setup_private = &which('ecryptfs-setup-private')

It says:
  adduser: Could not find program named 'ecryptfs-setup-private' in $PATH

We could emit another message, about apt-get install ecryptfs-utils, but I figured the user should be able to figure that out with command-not-found. (Perhaps even adduser's which() function should be taught to call command-not-found???)

However, the failed which() call exits adduser immediately, $?=1, which has succeeded in adding the user, but not in populating the home directory. Should it purge the user on failed exit?

For the adduser.conf request, I filed Bug #305582 and assigned to myself. I'll submit another patch for that.

:-Dustin

Settled IRL, but for the record: which should be called (and abort) right after option parsing, to avoid having to rollback anything.

Updated patch attached.

This patch introduces two changes based on Martin's feedback...
 1) drops ecryptfs-utils from a Recommends to a Suggests
 2) moves the &which() call to the parameter sanity checking section, such that calling adduser --encrypt-home when ecryptfs-setup-private is not installed will yield a meaningful error message and exit non-zero before half-adding a user to the system.

I've retested and this seems to work much better. Thanks for the suggestion and the careful review!

Cheers,
:-Dustin

This bug was fixed in the package adduser - 3.110ubuntu2

---------------
adduser (3.110ubuntu2) jaunty; urgency=low

  * Fixes for LP: #302870
  * adduser: add support for setting up an encrypted home directory, calling
    ecryptfs-setup-private to do the hard work
  * doc/adduser.8: document the --encrypt-home option
  * debian/control: suggest ecryptfs-utils >= 67-1

 -- Dustin Kirkland <email address hidden> Fri, 05 Dec 2008 22:25:34 -0800

ecryptfs kernel module needed in the installer for the user-setup changes.

:-Dustin

Patch attached for user-setup. This patch adds support for adduser --encrypt-home, and the corresponding dialog. It also drastically simplifies the process by removing the more complicated encrypted-private support.

Note that the sponsor should run debconf-updatepo (or the like) to update the translations from the modified template.

I'm requesting sponsorship of this package, but I should note that the ecryptfs.ko module will need to be added to the d-i kernel for this to work in the installer!

:-Dustin

Evan, Colin, would you mind reviewing and committing the user-setup change from Dustin? Thanks!

git commit log message 'UBUNTU: Build ecryptfs into the kernel'

This bug was fixed in the package user-setup - 1.23ubuntu2

---------------
user-setup (1.23ubuntu2) jaunty; urgency=low

  [ Dustin Kirkland ]
  Changes for LP: #302870
  * user-setup-apply: Add support for adduser --encrypt-home; remove
    deprecated encrypted-private (replaced in the installer by
    encrypted home support)
  * debian/user-setup-udeb.templates: Add encrypt-home debconf question;
    remove deprecated encrypted-private
  * user-setup-ask: prompt for encrypt-home; remove the more complicated
    encrypted-private dialogs

 -- Evan Dandrea <email address hidden> Wed, 10 Dec 2008 13:50:38 -0800

This bug was fixed in the package linux - 2.6.28-3.4

---------------
linux (2.6.28-3.4) jaunty; urgency=low

  [ Tim Gardner ]

  * Build ecryptfs into the kernel
    - LP: #302870
  * Deprecated gnbd

  [ Upstream Kernel Changes ]

  * Rebased to v2.6.28-rc8

 -- Tim Gardner <email address hidden> Wed, 10 Dec 2008 22:45:13 -0700

Surely, rather than building ecryptfs into the kernel, it would have been better to put it in the crypto-modules udeb?

What's the downside of building it in? Pursuant to UDS discussions regarding faster boot we're considering building in even more modules, especially file systems, e.g., modules that are boot essential or related to boot essential modules. I think ecryptfs and it's encryption dependent modules are quite safe to build into the kernel.

fresh install of Ubuntu Jaunty (downloaded today from daily) using amd64 and netboot to install the system. Once the system came up everything was normal except that I could not login.

I tried everything I could think of to allow the user to write to its $HOME but it seems that .ecryptfsrc wasn't created (on purpose?) or there is a race condition between the keyring and ecryptfs (if keyring wasn't created for some reason, the script that unwraps the password can't put it on the keyring and the keyring cannot be created because when you login you can't write to home as it has 0500 permissions).

Please advice....

this is a test system with the following hardware:

IBM leonovo R61 (amd64)

I installed from the Alternate ISO using tftp and the system was partitioned like the following (preseed):

d-i partman-auto/expert_recipe string \
      boot-root :: \
              100 10000 256 ext4 \
                      $primary{ } $bootable{ } \
                      method{ format } format{ } \
                      use_filesystem{ } filesystem{ ext3 } \
                      mountpoint{ /boot } \
              . \
              5000 9999 10000 ext4 \
                      $lvmok{ } \
                      method{ format } format{ } \
                      options/relatime{ relatime } \
                      use_filesystem{ } filesystem{ ext4 } \
                      mountpoint{ / } \
              . \
              256 3000 300% linux-swap \
                      $lvmok{ } \
                      method{ swap } format{ } \
              . \
              500 3000 40000 ext4 \
                      $lvmok{ } \
                      method{ format } format{ } \
                      options/relatime{ relatime } \
                      use_filesystem{ } filesystem{ ext4 } \
                      mountpoint{ /home } \
              . \
              500 1000 1024 ext4 \
                      $lvmok{ } \
                      method{ format } format{ } \
                      options/relatime{ relatime } \
                      use_filesystem{ } filesystem{ ext4 } \
                      mountpoint{ /tmp } \
              . \
              500 1000 1024 ext4 \
                      $lvmok{ } \
                      method{ format } format{ } \
                      options/relatime{ relatime } \
                     ...

partitions map for preseed

On Thu, Jan 15, 2009 at 3:38 PM, LuisMondesi wrote:

> fresh install of Ubuntu Jaunty (downloaded today from daily) using amd64
> and netboot to install the system. Once the system came up everything
> was normal except that I could not login.

Dustin, this sounds like the same issue that we ran into at UDS on my
laptop. Luis, I'd recommend filing a bug (I don't know of one that exists
for this) and then putting a link to it here in the comments. Thanks!

Server or desktop installer?

:-Dustin

@Michael Rooney

Ummmm... I'll fill out a propper bug and link to this then.

@Dustin Kirkland

I used the desktop (alternate) installer and grab the netboot folder from it.

I filed a new bug:
https://bugs.launchpad.net/ecryptfs/+bug/317895

This bug was fixed in the package gnome-system-tools - 2.29.3-0ubuntu1

---------------
gnome-system-tools (2.29.3-0ubuntu1) lucid; urgency=low

  * New upstream release (LP: #506365)
    - Move to new System Tools Backends protocol (new liboobs API).
      We now only commit changes to one user at a time, reducing the
      risk for dangerous bugs.
    - Include default profiles configuration file (user-profiles.conf).
      Distributors should modify it to suit their needs and send them
      back for inclusion.
    - When creating an user, don't force UID, main group, home directory
      and shell: these parameters are now handled (better) by the platform
      tools (LP: #488158, LP: #313990)
    - Allow removing home directory when deleting an user (LP: #426125).
    - Don't allow deleting the last administrator account, and warn when
      the user is losing its own admin rights. Same for active users
      (LP: #25947, LP: #349453)
    - Don't allow creating a group with an existing GID (LP: #491434)
    - Use UID and GID ranges defined by liboobs, depending on the platform's
      abilities.
    - Clear suggested login entry when Real name is emptied in the new user
      dialog.
    - Change GConf "showall" option to apply only on users. System groups are
      always shown, since they are the most interesting ones.
    - Various UI and string improvements.
    - Change password for current user by running 'passwd', to avoid
      breaking keyrings and encrypted dirs
    - Ask for PolicyKit authentication when it most makes sense, i.e.
      when showing dialogs
    - Option to set encrypted home directories when creating users (on
      platforms that support it) (LP: #302870)
    - When editing one group, only commit changes to that group
    - When changing Real name, update it in the users list (LP: #498970)
    - Select current user on start, and the first one after selected user
      has been deleted
    - Don't force updating configuration twice on start
  * Also fixes LP: #344182, LP: #208057, LP: #188757, LP: #372695,
    LP: #99276, LP: #160862
  * debian/control:
    - Bump liboobs-dev build-dep to 2.29.3
  * debian/gnome-system-tools.install:
    - Don't install debian/profile
    - Install upstream user-profiles.conf instead
  * Delete debian/profiles
  * Refreshed patches:
    - 25_sambashare_group_definition.patch
    - 90_relibtoolize.patch
  * Dropped debian/patches/85_user_gnome_about_me_for_password.patch:
    - The change is obsolete in the new version
  * debian/patches/82_gst-packages-time-admin.patch:
    - Updated to remove superfluous UI file changes, causing focus issues
      in the users-admin password change dialog. Thanks to Will for
      spotting this (LP: #501976)
 -- Chris Coulson <email address hidden> Fri, 05 Feb 2010 15:30:10 +0000