yahoo-eng-team team mailing list archive

[Chad Smith <1849677@xxxxxxxxxxxxxxxxxx>]

This bug is believed to be fixed in cloud-init in version 19.2-72. If
this is still a problem for you, please make a comment and set the state
back to New

Thank you.

** Changed in: cloud-init
       Status: Fix Committed => Fix Released

-- 
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/1849677

Title:
  azure locks existing user if instance id changes

Status in cloud-init:
  Fix Released

Bug description:
  The same bug was actually reported by someone else as a waagent bug here:
  https://github.com/Azure/WALinuxAgent/issues/454

  But was closed due to no followup of original user.

  Cloud Provider: Azure
  VM: Ubuntu 14.04 (And probably all higher versions)

  When provisioning a VM on Azure, cloud-init uses /dev/sr0 to find ovf-env.xml.
  Since the instance is new, cc_users_groups which runs "per instance" and adds my user which is configured with a password (not ssh-key) to the system.

  Now cloud-init copies ovf-env.xml to /var/lib/waagent/ to be used as a cache.
  But the password is changed to REDACTED.

  Notice that on following boots, when cloud-init loads DataSourceAzure, it uses /var/lib/waagent/ovf-env.xml and the password is REDACTED, and therefore is considered as no password:
  https://github.com/cloud-init/cloud-init/commit/8af1802c9971ec1f2ebac23e9b42d5b42f43afae#diff-e0eb215db26e21dbe2d98455fea68595R601
  So DataSourceAzure does not configure defuser["lock_passwd"] = False, it is True by default and now the defuser configuration contains a directive to lock this user account.

  Usually everything works and the the user never gets locked since we
  are using the same instance, and cc_users_groups never gets invoked
  (which is a per instance action), but when the instance id does change
  (when exporting the disks to a different machine) the user will get
  locked by create_user() with defuser["lock_passwd"] = True.

  I guess the correct logic should have been:

      if password:
          defuser['lock_passwd'] = False
          if DEF_PASSWD_REDACTION != password:
              defuser['passwd'] = encrypt_pass(password)

  In this case create_user() will be invoked, add_user() will not do
  anything since the user exists and no locking will occur later on in
  create_user().

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