[16.04.6 Desktop] Cannot log in after installation with encrypted home enabled

Bug #1817689 reported by Jean-Baptiste Lallement
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
Fix Released
Critical
Unassigned
Xenial
Fix Released
Critical
Unassigned
user-setup (Ubuntu)
Fix Released
Critical
Unassigned
Xenial
Fix Released
Critical
Unassigned

Bug Description

Ubuntu Desktop 16.04.6 20190222

Test Case
Do an entire disk installation and on the 'Who are you' page select "encrypt home", reboot and log in from lightdm

Actual Result
The log in is rejected. There are permission denied in the logs (journal attached)

This is a *regression* in 16.04.6. It works fine on 16.04.5.

The following message appears in the logs:
""""
user-setup: Error: Your kernel does not support filename encryption
user-setup: ERROR: Could not add passphrase to the current keyring
user-setup: adduser: `/usr/bin/ecryptfs-setup-private -b -u u' returned error code 1. Exiting.
""""

This is with kernel 4.15.0-45-generic
16.04.5 uses kernel 4.15.0-29-generic

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 4.15.0-45.48~16.04.1-generic 4.15.18
Uname: Linux 4.15.0-45-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Tue Feb 26 06:10:00 2019
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd quiet splash --- apt-setup/restricted=false apt-setup/multiverse=false
InstallationDate: Installed on 2019-02-26 (0 days ago)
InstallationMedia: Ubuntu 16.04.6 LTS "Xenial Xerus" - Release amd64 (20190222)
ProcEnviron:
 TERM=linux
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :
summary: - Cannot log in after installation with encrypted home enabled
+ [16.04.6 Desktop] Cannot log in after installation with encrypted home
+ enabled
description: updated
description: updated
description: updated
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1817689

tags: added: iso-testing
description: updated
Changed in ubiquity (Ubuntu):
status: New → Confirmed
importance: Undecided → Critical
Changed in ubiquity (Ubuntu Xenial):
status: New → Confirmed
importance: Undecided → Critical
Revision history for this message
Jean-Baptiste Lallement (jibel) wrote :

Installer log for 16.04.5 (successful setup of ecryptfs)

Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Observations so far: the issue can only be seen during ubiquity install in user-setup. If you run something like `adduser --encrypt-home user` on the installed system or on the live system, everything just works.

Apparently adduser fails on ecryptfs with "user-setup: Error: Your kernel does not support filename encryption". This string comes from ecryptfs_add_passphrase.c in ecryptfs-tools and is only printed if there's a problem in reading /sys/fs/ecryptfs/version or if the version doesn't support filename encryption (it's a binary flag on the version number). Checking /sys/fs/ecryptfs/version at any time of the installation process (either in the live part or in /target), the version seems to support what's needed.

Could it be that for some reason user-setup runs before sysfs is mounted in /target/sys/ ? And therefore unable to perform the setup since the version path does not exist? Or maybe some permission error? Why does that only happen now and not on .5?

Changed in ubiquity (Ubuntu Xenial):
milestone: none → ubuntu-16.04.6
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

So apparently right before the adduser call in user-setup (and also right after it), /sys/fs/ecryptfs/version on target is readable and correct. However, Laney noticed through debugging right after adduser runs that in fact the ecryptfs tools are not able to read the version number anyway. There seems to be something strange going on in it's get_version() function?

Revision history for this message
Iain Lane (laney) wrote :

That function does some interesting stuff to find out where a sysfs is mounted. It's broken because for some reason (don't know why), /proc isn't mounted inside the chroot when we run adduser.

AFAICT user-setup is wrong here though - it calls adduser which calls into ecryptfs. It ensures /sys is mounted but not /proc.

I don't know what was making this work before. I'm proposing to fix this directly and not track that down since it seems fairly clear that user-setup is buggy in this respect anyway.

Changed in user-setup (Ubuntu):
importance: Undecided → Critical
Changed in user-setup (Ubuntu Xenial):
importance: Undecided → Critical
Revision history for this message
Łukasz Zemczak (sil2100) wrote : Please test proposed package

Hello Jean-Baptiste, or anyone else affected,

Accepted user-setup into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/user-setup/1.63ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in user-setup (Ubuntu Xenial):
status: New → Fix Committed
tags: added: verification-needed verification-needed-xenial
Revision history for this message
Łukasz Zemczak (sil2100) wrote :

Hello Jean-Baptiste, or anyone else affected,

Accepted ubiquity into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/2.21.63.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Changed in ubiquity (Ubuntu Xenial):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package user-setup - 1.63ubuntu4.1

---------------
user-setup (1.63ubuntu4.1) xenial; urgency=medium

  * Mount /proc before calling adduser --encrypt-home. This calls into
    ecryptfs, which requires a /proc in order to find out where sysfs is
    mounted. (LP: #1817689)

 -- Iain Lane <email address hidden> Tue, 26 Feb 2019 18:43:44 +0000

Changed in user-setup (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ubiquity - 2.21.63.10

---------------
ubiquity (2.21.63.10) xenial; urgency=medium

  * Automatic update of included source packages: user-setup
    1.63ubuntu4.1. (LP: #1817689)

 -- Łukasz 'sil2100' Zemczak <email address hidden> Tue, 26 Feb 2019 21:37:01 +0100

Changed in ubiquity (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in user-setup (Ubuntu):
status: New → Confirmed
Revision history for this message
Will Cooke (willcooke) wrote :

Confirming that this is fixed in the .1 image today.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package user-setup - 1.63ubuntu6

---------------
user-setup (1.63ubuntu6) disco; urgency=medium

  * Mount /proc before calling adduser --encrypt-home. This calls into
    ecryptfs, which requires a /proc in order to find out where sysfs is
    mounted. (LP: #1817689)

 -- Iain Lane <email address hidden> Wed, 27 Feb 2019 16:48:22 +0000

Changed in user-setup (Ubuntu):
status: Confirmed → Fix Released
tags: added: id-5c6336963839c84091fe6817
Will Cooke (willcooke)
tags: added: verification-done-xenial
removed: verification-needed-xenial
Iain Lane (laney)
Changed in ubiquity (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.