[Bug 1258900] Re: Ecryptfs,cryptsetup p/w prompt enter key failures

[MetaChrome]

>What are you expecting this to do? crypto_LUKS is not a filesystem.
There's no way this is going to do anything meaningful.

crypto_LUKS is a mount extension provided by libpam-mount and its
functionality does not fail outside of the scope of the specified
behavior.

that is the package specified as provided by `apt-cache show
cryptsetup`.

http://pastebin.com/G5Ynhtix

This package is possibly relevant because crypt_LUKS probably functions
along the lines of being a script that does:

losetup
cryptsetup
mount

>cryptsetup does not at boot prompt for passphrases in Ubuntu. It
communicates with plymouth for prompting. Please provide >information
about the plymouth configuration on your machine (including
/proc/cmdline).

plymouth version information: http://pastebin.com/zCLrGUms

>ecryptfs is designed for cases where an encrypted filesystem is *not*
mounted at boot, but instead mounted at user login (and >unmounted at
user logout). I have no idea what the behavior is of ecryptfs if used
from /etc/fstab. How is ecryptfs prompting >for a passphrase? If it is
bypassing plymouth, then this is a bug in ecryptfs-utils, and the error
you're experiencing is because >it's fighting plymouth for the console.
Plymouth owns the console exclusively at boot.

1. Considering that the issues are quite similar on 2 different password prompts, please consider the possibility that this behavior is caused outside the scope ecryptfs despite the possibility of a lack of explicit support for mounting at boot. 
2. Please consider whether there is an explicit expectation of the specified failure. 

Please consider whether there is no implicit support for mount at boot
or implicit interaction with the plymouth package. I don't know the
abstractions provided by boot/plymouth, but would not a generic prompt
for input, be correctly handled at boot, without the need for
interfacing with plymouth, facilitating an implicit expectation of
functionality at boot?

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/1258900

Title:
  Ecryptfs,cryptsetup p/w prompt enter key failures

Status in cryptsetup:
  New
Status in “cryptsetup” package in Ubuntu:
  Incomplete
Status in “ecryptfs-utils” package in Ubuntu:
  New

Bug description:
  1. With ecryptsfs:

  /etc/fstab:
  /root/ecfs_data /root/ecfs ecryptfs rw,exec,suid 0 0

  a) Pressing the enter key quickly with no other input returns that some input is required.
  b) Pressing the enter key the first time subsequent to some input appears to append a return character to the password string. Pressing the enter subsequent to that submits the now incorrect password resulting in failure.
  c) If you hold the enter key, it sends multiple return characters, some times some of them appear to be appended to the password string, until eventually they start being sent to subsequent prompts.  It would appear that sometimes multiple return characters are added to the password string because the signatures change on various attempts.

  c) may be relevant in the sense that the holding the enter key in #2
  facilitates a workaround.

  2. The password prompt created by cryptsetup exhibits similar behavior
  but can be worked around by holding the enter key.

  /etc/fstab:
  /root/e_data /root/e crypto_LUKS defaults 0 0

  b) Pressing the enter key without any input specifies that the password was incorrect.
  a) Pressing the enter key the first time subsequent to some input appears to append a return character to the password string. A subsequent press of the enter key submits the now incorrect password.
  c) Holding the enter key subsequent to entering the password facilitates mounting. However, there are no further messages specifying success. Boot continues.

  In both instances of #1 and #2, the data from previous boot
  instructions appears past the `Password:` semicolon, ie:

  Password: /dev/sda1: 333 files, 13026/126976 clusters

  This does not appear to affect the success of 2.c.

  3. The following may look like it is unrelated but consider the fact
  that the password prompt is not halted and the fact that this should
  in fact work.

  The reason why I think the following is related is because I think
  that it's possible that it is returning from the password prompt and
  failing the crypttab execution asynchronously if that is perhaps how
  the relevant executables (upstart?) operate.

  /etc/crypttab:
  swap_e /dev/sda8 /dev/urandom swap

  /etc/fstab:
  /dev/mapper/swap_e none swap sw 0 0 #<-- if this is before the next line, it specifies that /dev/mapper/swape does not exist, and auto returns from the ecryptfs password prompt
  /root/ecfs_data /root/ecfs ecryptfs rw,exec,suid 0 0

  As specified, when the ecryptfs mount entry in fstab is after the swap
  mount, it specifies that the /dev/mapper/swape disk does not exist and
  auto skips the ecryptfs mount, auto returning from the password prompt
  and said mount failure is not recorded in /var/log/boot.log.

  System:

  Ubuntu 12.04.3 LTS
  ecryptfs-utils 96-0ubuntu3
  cryptsetup-luks 2:1.6.1-1ubuntu1
  libpam-mount 2.14-1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cryptsetup/+bug/1258900/+subscriptions