[Bug 2150646] Re: Home directory has wrong ownership if the user exists but the home directory itself is missing when cloud-init runs on first boot

[Marius Gedminas]

No reproducer yet, but I looked through github issues mentioning /home
and saw some helpful pointers that lead me to where I think the bug is
in the code.

https://github.com/canonical/cloud-
init/blob/8adfc0e7f418b2190b5936c93bd8ac236213b65d/cloudinit/ssh_util.py#L329
does this:

1. given filename like '/home/username/.ssh/authorized_keys', set directories to ['home', 'username', '.ssh']
2. set home_folder = '/home' according to os.path.dirname(user_pwent.pw_dir)
3. loop through all the parent directories in order, setting parent_directory to '/home', '/home/username', '/home/username/.ssh'.
4. for parent_directory == '/home' it will check if home_folder.startswith(parent_folder) and since that's true (home_folder == parent_folder at this point) it will continue to the next loop iteration
5. for parent_directory == '/home/username' it will check if parent_folder == user_pwent.pw_dir, which is true, and then it will continue to the next loop iteration
6. for parent_directory == '/home/username/.ssh' it will check os.path.exists(parent_folder) and then it will call os.makedirs(parent_folder, mode=mode, exist_of=True).

os.makedirs('/home/username/.ssh') will create all missing parent
directories, specifically /home/username, using the default mode (0o777,
which is affected by the umask producing 0o755), and owned by the user
that cloud-init runs as (root:root).

Then cloud-init will chown /home/username/.ssh to be owned by the user,
but it will never chown the /home/username itself.

Previous conversations (https://github.com/canonical/cloud-
init/pull/984#discussion_r690539832) hint that this is not supposed to
happen (check_create_path should fail instead of creating
/home/username), but since the code used os.makedirs() instead of
os.makedir(), this is what actually happens.

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

Title:
  Home directory has wrong ownership if the user exists but the home
  directory itself is missing when cloud-init runs on first boot

Status in cloud-init package in Ubuntu:
  Incomplete
Status in subiquity package in Ubuntu:
  Incomplete

Bug description:
  I'm adapting a custom autoinstall script to Ubuntu 26.04 LTS.  The
  last thing it does in curtin's late-commands is execute a script that
  juggles some btrfs subvolumes and /etc/fstab mountpoint, with the end
  result of /home being an empty btrfs subvolume on first boot.

  Then cloud-init runs and somewhere in either modules-final/config-
  scripts_user or in modules-final/config-ssh_authkey_fingerprints ends
  up creating a mostly-empty /home/$username directory owned by
  root:root, mode 0755.  (I'm blaming those modules based on timestamps
  of log entries in /var/log/cloud-init.log, correlated with the inode
  birth timestamp of /home/$username, as reported by stat(1).  Also, the
  very next log entries talk about modules-final/config-
  ssh_authkey_fingerprints fixing the ownership of /home/$username/.ssh,
  which makes me suspect there's some sort of mkdir -p or the Python
  equivalent happening.)

  I'll fix our btrfs massaging script, but it would be nice if cloud-
  init wouldn't create home directories with incorrect
  ownership/permissions.

  This is somewhat similar (but more or less the opposite of) bug
  #1665943.

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