ecryptfs-setup-private fails if passphrase contains character "%"

Bug #290445 reported by Pekka Tiittanen on 2008-10-28
32
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Robbie Williamson
eCryptfs
Undecided
Unassigned
ecryptfs-utils (Ubuntu)
High
Dustin Kirkland 
Intrepid
High
Dustin Kirkland 

Bug Description

Binary package hint: ecryptfs-utils

Ecrypt-setup-private asks for user login passphrase, but it seems to fail if there are certain special characters in passphrase (for me that would be %).

I'm running Ubuntu 8.10
ecryptfs-utils version 53-1ubuntu11

Dustin Kirkland  (kirkland) wrote :

Thanks, I'm working on a fix.

As a work around, you can enter two "%" back to back to escape. Example, for a password of "foo%bar", you could enter "foo%%bar".

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Attached patch solves the problem. This should be a clear candidate for an Intrepid SRU.

I'm committing upstream as well.

:-Dustin

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

As I said above, this should be a clear case for an SRU for Intrepid.

I do not believe this is a release critical bug, because it only affects:
 - users of the alternate/server iso
 - who have a "%", or a "-" in their chosen passphrase
 - and have elected to setup an encrypted private directory in the installer.

When this occurs, the ecryptfs-setup-private step fails, however, the installation proceeds normally. Upon reboot, the user will find that their encrypted ~/Private directory is not mounted, and with permission 0500 (r-x------), and thus no data should be written there.

To remedy the problem after the first boot, the user will need to upgrade ecryptfs-utils (to the version we will SRU), and then run "ecryptfs-setup-private --force" to reconfigure their encrypted ~/Private directory correctly.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Blurb for the release notes:

Users of the alternate/server installation who choose a password containing a "%" or a "-" will end up with an encrypted ~/Private directory that will not mount on reboot and subsequent logins. To fix this, affected users will need to do the following in the newly installed system:
 $ sudo apt-get update
 $ sudo apt-get upgrade ecryptfs-utils
 $ ecryptfs-setup-private --force

:-Dustin

Robbie Williamson (robbiew) wrote :

Documented in Intrepid release notes.

Changed in ubuntu-release-notes:
assignee: nobody → robbie.w
status: New → Fix Released
Steve Langasek (vorlon) wrote :

I don't think there's any reason to specify use of 'apt-get' in the release notes, though; most desktop users will be unfamiliar with this and IMHO it would be better to just tell them to "get the updates".

Changed in ubuntu-release-notes:
status: Fix Released → In Progress
Dustin Kirkland  (kirkland) wrote :

Updated blurb for the release notes:

Users of the alternate/server installation who choose a password containing a "%" or a "-" will end up with an encrypted ~/Private directory that will not mount on reboot and subsequent logins. To fix this, affected users will need to do the following in the newly installed system:
 - Update ecryptfs-utils to the latest available in the archive, and then run:
 $ ecryptfs-setup-private --force

:-Dustin

Robbie Williamson (robbiew) wrote :

Updated release notes with changes.

Dustin Kirkland  (kirkland) wrote :

Updated blurb for the release notes:

Users of the alternate/server installation who choose a password containing a "%" or a "-" will end up with an encrypted ~/Private directory that will not mount on reboot and subsequent logins. To fix this, affected users will need to do the following in the newly installed system:
 - Update ecryptfs-utils to at least version 53-1ubuntu12 (as soon as it becomes available as a package update), and then run:
 $ ecryptfs-setup-private --force

:-Dustin

Jamie Strandboge (jdstrand) wrote :

Uploaded to intrepid-proposed. Dustin, please follow the SRU process for getting this into -updates.

Changed in ecryptfs-utils:
status: In Progress → Fix Committed
Robbie Williamson (robbiew) wrote :

Updated release notes with changes from comment #9.

Changed in ubuntu-release-notes:
status: In Progress → Fix Released
Martin Pitt (pitti) wrote :

Accepted into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

jalbrant (jeremiah-albrant) wrote :

The upstream v61 does not have this issue as they have no longer use printf to check the user's password as 53-1ubuntu does on line 148.

Dustin Kirkland  (kirkland) wrote :

jalbrant-

I committed these changes upstream. We're in sync.

:-Dustin

Dustin Kirkland  (kirkland) wrote :

Per https://wiki.ubuntu.com/StableReleaseUpdates:

 1) This bug will impact any user wishing to setup an encrypted ~/Private directory having a "%" or a "-" in their login password or their mount passphrase.

 2) This was fixed in Intrepid's ecryptfs-utils_53-1ubuntu12, which is in Intrepid -proposed

 3) The fix involves 3 trivial changes, basically changing:
     printf "$foo" ------> printf "%s" "$foo"
  The upstream git commit is:
   * http://git.kernel.org/?p=linux/kernel/git/mhalcrow/ecryptfs-utils.git;a=commit;h=2c422e6d2549f90258cddeebf105b066b598bdbb

 4) TEST CASE:
    Using ecryptfs-utils_53-1ubuntu11 (or the Intrepid alternate/server) install media, set a user's password to something like "foo%bar". Then run "ecryptfs-setup-private". You will be prompted for your system password. If you correctly enter "foo%bar", you will be told that your entered login passphrase is incorrect.
    Using ecryptfs-utils_53-1ubuntu12, the above test case should succeed.

 5) I believe the regression potential to be very low. I'm attaching to this bug a shell script I used to test, by generating 10,000 random passwords including all sorts of alphanumeric and punctuation characters, and testing the output of a printf "%s" "$foo". You can use this "fuzzing" test to verify the change. I ran this numerous times.

:-Dustin

Martin Pitt (pitti) wrote :

Copied intrepid-proposed version to jaunty.

Changed in ecryptfs-utils:
status: Fix Committed → Fix Released

On Mon, Nov 3, 2008 at 1:12 AM, Martin Pitt <email address hidden> wrote:
> Copied intrepid-proposed version to jaunty.

Thanks, I also fixed this upstream, so I'll do a merge/sync to a more
recent upstream version today (or very soon, rather).

:-Dustin

Martin Pitt (pitti) wrote :

I verified that I get the password failure with the intrepid final version, and that it works correctly with the intrepid-proposed version.

Copied to intrepid-updates.

Changed in ecryptfs-utils:
status: Fix Committed → Fix Released
Changed in ecryptfs:
status: Fix Committed → Fix Released
Changed in ecryptfs-utils (Ubuntu):
assignee: Dustin Kirkland (kirkland) → marcjpouliot (marc-pouliot)
status: Fix Released → Incomplete
Steve Langasek (vorlon) on 2009-12-14
Changed in ecryptfs-utils (Ubuntu):
status: Incomplete → Fix Released
assignee: marcjpouliot (marc-pouliot) → Dustin Kirkland (kirkland)
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

Bug attachments