no sysfs entry in /etc/mtab breaks encrypted-home

Bug #802197 reported by Scott Moser on 2011-06-26
112
This bug affects 16 people
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Medium
Dustin Kirkland 
util-linux (Ubuntu)
Critical
Steve Langasek

Bug Description

encrypted-home directories were broken with the latest upgrade of util-linux.

The issue is that ecryptfs tries to find a sysfs mount point by reading /etc/mtab (ie, it wants to find 'sysfs' and '/sys').

in ecryptfs/src/libecryptfs/sysfs.c , ecryptfs_get_version tries to get the version of ecryptfs in this kernel. and then see if it is capable. That calls 'get_sysfs_mountpoint' which parses /etc/mtab for the sysfs entry.

The util-linux upgrade to 2.19.1-2ubuntu1 does not write an entry in /etc/mtab for sysfs.

The end resupt is that the user ends up with file *content* decrypted, but not filenames. They'll see a bunch of filenames with "ECRYPTFS_FNEK_ENCRYPTED" in their name like:
 ECRYPTFS_FNEK_ENCRYPTED.FXbGolSeisjWM-Qojv3ajQsDcC-kITIu0KUxZdKsa5gkZBtZLX12p7AKgcrQTja6Hep3FSW8okccMX6-
ECRYPTFS_FNEK_ENCRYPTED.FXbGolSeisjWM-Qojv3ajQsDcC-kITIu0KUxZdKsa5gkZBtZLX12p7AKggO-5p.pSThbVFaNI8aX4-6-
ECRYPTFS_FNEK_ENCRYPTED.FXbGolSeisjWM-Qojv3ajQsDcC-kITIu0KUxZdKsa5gkZBtZLX12p7AKgirB.sNgfbm-8lk0XZWwB-A-

1 possible fix for this is for ecryptfs to read /proc/mounts rather than /etc/mtab.
A work around for this is to:
 a.) log in as another user, edit /etc/mtab and add 'sysfs' entry (see /proc/mounts for example), then log in as new user
 b.) backlevel util-linux and reboot (so /etc/mtab is updated with sysfs entry via old util-linux).

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: util-linux 2.19.1-2ubuntu1
ProcVersionSignature: Ubuntu 3.0-1.2-generic 3.0.0-rc3
Uname: Linux 3.0-1-generic x86_64
Architecture: amd64
Date: Sun Jun 26 10:50:31 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Beta amd64 (20100318)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: util-linux
UpgradeStatus: Upgraded to oneiric on 2010-11-15 (222 days ago)

Scott Moser (smoser) wrote :
Changed in util-linux (Ubuntu):
importance: Undecided → High
status: New → Confirmed
Michael Terry (mterry) wrote :

For others affected by this, here's the mtab line to add:

sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0

And if you had previously logged in as the affected user, you'll now have duplicate files in your home directory (e.g. a normal Pictures folder and the encrypted-filename Pictures folder).

To clean up:
1) Go to /home/.ecryptfs/USER/.Private
2) Move anything not called ECRYPT* to a safe place to get it out of the way
3) Then finally log in as the affected user again

Changed in util-linux (Ubuntu):
importance: High → Critical
Changed in ecryptfs-utils (Ubuntu):
importance: Undecided → Critical
status: New → Triaged
Changed in util-linux (Ubuntu):
status: Confirmed → Triaged
assignee: nobody → Steve Langasek (vorlon)
Dustin Kirkland  (kirkland) wrote :

Assigning to Steve for now...

Steve, can you comment if this change in behavior from util-linux is intended?

ie, does util-linux need to be fixed to go back to adding a sys entry to /etc/mtab?

Or do I need to go and fix ecryptfs-utils to read something other than /etc/mtab?

Dustin Kirkland  (kirkland) wrote :

Talked to Steve in IRC, who redirected me to Lamont.

Lamont? Is this change in behavior intended?

Changed in util-linux (Ubuntu):
assignee: Steve Langasek (vorlon) → LaMont Jones (lamont)
description: updated
Scott Moser (smoser) wrote :

I updated the description above, in some places I *had* written /etc/fstab, when '/etc/mtab' is what I meant.

Dustin Kirkland  (kirkland) wrote :

Possible patch to ecryptfs-utils attached, loops over both /etc/mtab and /proc/mounts. Untested yet, but if we need to fix this in ecryptfs-utils, this is probably a viable approach.

Dustin Kirkland  (kirkland) wrote :

Ignore that patch 'out'. Tested it, it does not work. Confirmed that Michael Terry's line added to /etc/mtab does fix this:
  sysfs /sys sysfs rw,noexec,nosuid,nodev 0 0

There's more references to /etc/mtab than just the one I patched. We need to get util-linux fixed.

tags: added: patch
PeterPall (peterpall) wrote :

Only if to make sure that everybody has a workaround for the time the fix that addresses the real problem is published and distributed:
A temporary workaround that users affected by this bug could apply would be

- Open a terminal and type
sudo gedit /etc/fstab
- Now a editor window opens. Add the following line to the end of the text this window contains:
sys /sys sysfs
- Save and close the editor.
- Done
After a reboot the sys filesystem is mounted by a different mechanism that during mounting it automatically adds the information about this to /etc/mtab.

Steve Langasek (vorlon) on 2011-06-29
Changed in util-linux (Ubuntu):
assignee: LaMont Jones (lamont) → Steve Langasek (vorlon)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package util-linux - 2.19.1-2ubuntu2

---------------
util-linux (2.19.1-2ubuntu2) oneiric; urgency=low

  * shlibs/mount/src/tab_update.c: don't refuse to update mtab when source
    is 'none'. LP: #802197.
 -- Steve Langasek <email address hidden> Wed, 29 Jun 2011 13:05:10 +0100

Changed in util-linux (Ubuntu):
status: Triaged → Fix Released
Chad Miller (cmiller) wrote :

If one trips over this bug, it may cause problems if that broken session creates files that shadow the old, valuable filenames that are encrypted.

If one is using the recommended scheme active during Karmic (at least), then this will find cleartext filenames that should not exist:

  $ ls -A /home/.ecryptfs/$USER/.Private |grep -v ECRYPTFS_FNEK

You might have a dozen or so. Move those to a new location, and after log out and unmount of that ecryptfs layer, and remount, the old files will reappear.

Something like this should help clean up:

  $ mkdir ~/Desktop/ecryptfs-bad-for-review
  $ mv /home/.ecryptfs/$USER/.Private/
  $ ls -A1 /home/.ecryptfs/$USER/.Private |grep -v ^ECRYPTFS_FNEK |while read filename; mv -i "/home/.ecryptfs/$USER/.Private/$filename" ~/Desktop/ecryptfs-bad-for-review/; done
  $ cd /home; sudo umount $USER
  $ ecryptfs-mount-private

Chad Miller (cmiller) wrote :

Er, that second line of script, "mv /home/.ecryptfs/$USER/.Private/" should not be there. Sorry.

Martin Pitt (pitti) wrote :

2.19.1-2ubuntu2 does _not_ cause sysfs to be back in /etc/mtab, and hence work around the ecrypts bug. Can anyone confirm this? From my POV this should be reopened.

On Wed, Jun 29, 2011 at 04:55:20PM -0000, Martin Pitt wrote:
> 2.19.1-2ubuntu2 does _not_ cause sysfs to be back in /etc/mtab, and
> hence work around the ecrypts bug. Can anyone confirm this? From my POV
> this should be reopened.

You installed libmount1 2.19.1-2ubuntu2, correct? (The buggy code is in
libmount1, not in the mount package itself.)

Have re-tested with the package from the archive, and It Works For Me.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Martin Pitt (pitti) wrote :

Ah, I'm sorry. With the updated libmount1 it indeed works again now. Previously I just grabbed the updated mount binary, just as I used to do with the downgrade to the natty version.

Dustin Kirkland  (kirkland) wrote :

Fixed in util-linux. Perhaps ecryptfs should be robust against a missing sysfs entry in mtab, though? Marking invalid for now, as it seems well fixed in util-linux.

Changed in ecryptfs-utils (Ubuntu):
status: Triaged → Invalid
Steve Langasek (vorlon) wrote :

As we discussed, ecryptfs's current behavior - probing the mtab to detect the location of sysfs at runtime - remains incorrect. /sys is the standard* location of this filesystem, there's no reason for ecryptfs to second guess this.

*standard: /sys will be included in the upcoming revision of the FHS.

Changed in ecryptfs-utils (Ubuntu):
importance: Critical → Low
status: Invalid → Triaged
Martin Pitt (pitti) wrote :

Also, reading /etc//mtab is really deprecated -- this file should have gone away eons ago. As a first and easy step, could ecryptfs at least parse /proc/self/mountstat? But just hardcoding /sys will do fine, as Steve says.

Dustin Kirkland  (kirkland) wrote :

Awesome, thanks Steve/Martin. (heh, "Steve Martin"!)

I'll get this fixed (hardcoded to /sys) in ecryptfs.

Changed in ecryptfs-utils (Ubuntu):
importance: Low → Medium
assignee: nobody → Dustin Kirkland (kirkland)
Changed in ecryptfs-utils (Ubuntu):
status: Triaged → In Progress
Dustin Kirkland  (kirkland) wrote :

Committed revision 613.

Changed in ecryptfs-utils (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :
Download full text (4.0 KiB)

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

---------------
ecryptfs-utils (96-0ubuntu1) precise; urgency=low

  [ Dustin Kirkland ]
  * CONTRIBUTING:
    - added a new file to describe how to contribute to ecryptfs
  * === added directory img/old, img/old/ecryptfs_14.png,
    img/old/ecryptfs_192.png, img/old/ecryptfs_64.png:
    - saving the old logos/branding for posterity
  * debian/copyright, img/COPYING:
    - added CC-by-SA 3.0 license
    - use the text version
  * img/ecryptfs_14.png, img/ecryptfs_192.png, img/ecryptfs_64.png:
    - added scaled copies of images used for Launchpad.net branding
  * src/utils/ecryptfs-recover-private: LP: #847505
    - add an option to allow user to enter the mount passphrase,
      in case they've recorded that, but forgotten their login
      passphrase
  * src/libecryptfs/sysfs.c: LP: #802197
    - default sysfs to /sys, if not found in /etc/mtab
    - it seems that reading /etc/mtab for this is outdated
    - ensure that ecryptfs works even if there is no sysfs entry
      in /etc/mtab
  * src/key_mod/ecryptfs_key_mod_tspi.c: LP: #462225
    - fix TPM and string_to_uuid 64bits issue
    - thanks to Janos for the patch
  * precise

  [ Tyler Hicks ]
  * CONTRIBUTING:
    - clarified how to contribute to the ecryptfs kernel module
  * tests/lib/etl_funcs.sh:
    - created eCryptfs test library of bash functions for use in test
      cases and test harnesses
  * test/etl_add_passphrase_key_to_keyring.c:
    - created a C helper program to allow bash scripts to interface to
      the libecryptfs function that adds passphrase-based keys to the
      kernel keyring
  * tests/kernel/tests.rc, tests/userspace/tests.rc:
    - created a test case category files for test harnesses to source
      when running testcases of a certain category (destructive, safe,
      etc.)
  * tests/run_tests.sh:
    - created a test harness to run eCryptfs test cases
  * tests/kernel/miscdev-bad-count.sh,
    tests/kernel/miscdev-bad-count/test.c:
    - created test case for miscdev issue reported to mailing list
  * tests/kernel/lp-885744.sh:
    - created test case for pathconf bug
  * tests/kernel/lp-926292.sh:
    - created test case for checking stale inode attrs after setxattr
  * tests/new.sh:
    - created new test case template to copy from
  * tests/userspace/verify-passphrase-sig.sh,
    tests/userspace/verify-passphrase-sig/test.c:
    - created test case, for make check, to test the creation of
      passphrase-based fekeks and signatures
  * configure.ac, Makefile.am, tests/Makefile.am, tests/lib/Makefile.am,
    tests/kernel/Makefile.am, tests/userspace/Makefile.am:
    - updated and created autoconf/automake files to build the new tests
      directory
    - added make check target

  [ Eddie Garcia ]
  * img/*: LP: #907131
    - contributing a new set of logos and branding under the CC-by-SA3.0
      license

  [ Colin King ]
  * tests/kernel/extend-file-random.sh,
    tests/kernel/extend-file-random/test.c:
    - Test to randomly extend file size, read/write + unlink
  * tests/kernel/trunc-file.sh, tests/kernel/trunc-file/test.c:
    - Test to exercise file truncation
  * tests/kernel/dir...

Read more...

Changed in ecryptfs-utils (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

Patches