yahoo-eng-team team mailing list archive

[James Falcon <1961620@xxxxxxxxxxxxxxxxxx>]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3952

** Bug watch added: github.com/canonical/cloud-init/issues #3952
   https://github.com/canonical/cloud-init/issues/3952

** Changed in: cloud-init
       Status: Triaged => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1961620

Title:
  cloud-init can add users in wrong filesystem (race with `mount /home`)

Status in cloud-init:
  Expired
Status in subiquity:
  New

Bug description:
  When cloud-init is used to configure a new Ubuntu Server system
  installed from the ISO images, and /home is configured as a separate
  partition, there is a (slow) race between the user creation and /home
  being mounted. This can lead to the user $HOME being created in the
  wrong filesystem.

  Steps to reproduce:

  1. Prepare to install focal-live-server-amd64.iso in a VM.
     In my case I used one of the 20.04.4 dailies.

  2. Proceed with all-defaults but for storage. Configure the storage
     so / is in a dedicated partition, while /home in a an *encrypted*
     LVM volume. (The only purpose of encryption is to add delay in the
     /home mount, see the next point.)

  3. Finish the install and reboot. At the dm-crypt password prompt
     stop and wait a few minutes. At some point cloud-init will proceed
     creating the configured username, but /home is not mounted yet!
     The user's $HOME is now in the same filesystem as /.

  4. Enter the dm-crypt password. This will cause /home to be mounted
     from the encrypted volume, and this will shadow the actual $HOME.

  5. Login with the configured credentials and verify that $HOME is
     inaccessible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1961620/+subscriptions