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

[Pekka Tiittanen]

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)]

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)]

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

I'm committing upstream as well.

:-Dustin

[Dustin Kirkland  (kirkland)]

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)]

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)]

Documented in Intrepid release notes.

[Steve Langasek (vorlon)]

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

[Dustin Kirkland  (kirkland)]

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)]

Updated release notes with changes.

[Dustin Kirkland  (kirkland)]

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)]

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

[Robbie Williamson (robbiew)]

Updated release notes with changes from comment #9.

[Martin Pitt (pitti)]

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)]

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)]

jalbrant-

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

:-Dustin

[Dustin Kirkland  (kirkland)]

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)]

Copied intrepid-proposed version to jaunty.

[Dustin Kirkland  (kirkland)]

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)]

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.