add support for setting up encrypted home directory on user creation

Bug #302870 reported by Dustin Kirkland  on 2008-11-27
24
This bug affects 2 people
Affects Status Importance Assigned to Milestone
eCryptfs
High
Dustin Kirkland 
adduser (Ubuntu)
High
Dustin Kirkland 
ecryptfs-utils (Ubuntu)
High
Dustin Kirkland 
gnome-system-tools (Ubuntu)
High
Unassigned
linux (Ubuntu)
High
Tim Gardner
system-tools-backends (Ubuntu)
Undecided
Unassigned
user-setup (Ubuntu)
High
Dustin Kirkland 

Bug Description

Binary package hint: adduser

I'm currently adding support for bootstrapping an encrypted home directory to the ecryptfs-setup-private utility in the ecryptfs-utils package.

This requires a simple patch to the adduser utility, to support an "--encrypt-home" option, which would call:
 # ecryptfs-setup-private -b -u $USER

The call to ecryptfs-setup-private uses the existing code to setup an encrypted home directory. It will generate a mount passphrase from /dev/urandom, establish the user's ecryptfs configuration files, mount the home directory, and return 0. With the home directory mounted, adduser can proceed to copy the /etc/skel files into the mounted, encrypted mountpoint. The adduser utility then needs to unmount that home directory. The "passwd" call within adduser will trigger the password-change code within pam_ecryptfs.so, which will detect the cleartext, randomly generated mount passphrase written to file, and wrap (ie, encrypt) that file using the chosen passphrase.

This patch also adds documentation to the manpage regarding the new --encrypt-home option.

Finally, this patch modifies the control file to "Recommend" a version of ecryptfs-utils with the required new functionality. Note that Colin said he needs to think about the appropriate level (Recommends vs. Suggests).

:-Dustin

Dustin Kirkland  (kirkland) wrote :

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

Changed in adduser:
assignee: nobody → kirkland
importance: Undecided → High
milestone: none → jaunty-alpha-2
status: New → In Progress
Dustin Kirkland  (kirkland) wrote :

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

:-Dustin

Changed in ecryptfs-utils:
assignee: nobody → kirkland
importance: Undecided → High
milestone: none → jaunty-alpha-2
status: New → In Progress
Dustin Kirkland  (kirkland) wrote :

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

:-Dustin

Changed in ecryptfs:
assignee: nobody → kirkland
importance: Undecided → High
status: New → In Progress
Dustin Kirkland  (kirkland) wrote :

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

Dustin Kirkland  (kirkland) wrote :

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

Changed in ecryptfs:
status: In Progress → Fix Released
Dustin Kirkland  (kirkland) wrote :

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

Changed in system-tools-backends:
importance: Undecided → High
milestone: none → jaunty-alpha-2
status: New → Triaged
Dustin Kirkland  (kirkland) wrote :

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

:-Dustin

Dustin Kirkland  (kirkland) wrote :

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

:-Dustin

Changed in system-tools-backends:
importance: High → Undecided
milestone: jaunty-alpha-2 → none
status: Triaged → Invalid
Changed in gnome-system-tools:
importance: Undecided → High
milestone: none → jaunty-alpha-2
status: New → Triaged
Changed in ecryptfs-utils:
status: In Progress → Fix Released
Dustin Kirkland  (kirkland) wrote :

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

This is ready for upload. Requesting sponsorship...

:-Dustin

Martin Pitt (pitti) wrote :

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)

Dustin Kirkland  (kirkland) wrote :

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

Martin Pitt (pitti) wrote :

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

Dustin Kirkland  (kirkland) wrote :

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

Launchpad Janitor (janitor) wrote :

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

Changed in adduser:
status: In Progress → Fix Released
Changed in user-setup:
assignee: nobody → kirkland
importance: Undecided → High
milestone: none → jaunty-alpha-2
status: New → In Progress
Dustin Kirkland  (kirkland) wrote :

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

:-Dustin

Changed in linux:
importance: Undecided → High
milestone: none → jaunty-alpha-2
status: New → Confirmed
assignee: nobody → timg-tpi
Dustin Kirkland  (kirkland) wrote :

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

Martin Pitt (pitti) wrote :

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

Tim Gardner (timg-tpi) wrote :

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

Changed in linux:
status: Confirmed → Fix Committed
Evan (ev) on 2008-12-10
Changed in user-setup:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in user-setup:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

Changed in linux:
status: Fix Committed → Fix Released
Colin Watson (cjwatson) wrote :

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

Tim Gardner (timg-tpi) wrote :

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.

Luis Mondesi (lemsx1) wrote :
Download full text (3.7 KiB)

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 } \
                     ...

Read more...

Luis Mondesi (lemsx1) wrote :

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!

Dustin Kirkland  (kirkland) wrote :

Server or desktop installer?

:-Dustin

Luis Mondesi (lemsx1) wrote :

@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.

Changed in gnome-system-tools (Ubuntu):
milestone: jaunty-alpha-2 → lucid-alpha-3
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-system-tools (Ubuntu):
status: Fix Committed → Fix Released
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

Related blueprints

Bug attachments