glassfish
  1. glassfish
  2. GLASSFISH-19031

Using asupgrade fails if existing domain has a non-default master password

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.2.2, 4.0
    • Fix Version/s: 4.0_b80_EE7MS6
    • Component/s: security
    • Labels:
      None

      Description

      (as reported on the users mailing list)

      Install GlassFish 3.1.2. Change the master password to something other than the default.

      Now go through the documented 3.1.2.2 upgrade process:
      Download GlassFish 3.1.2.2 and expand it into a different directory.
      Remove the 3.1.2.2 $

      {installDir}

      /glassfish/domains/domain1 directory.
      Run

      $

      {3.1.2.2-installDir}/glassfish/bin/asupgrade --console --source ${3.1.2-installDir}/glassfish/domains/domain1 --target ${3.1.2.2-installDir}

      /glassfish/domains

      and, when prompted, enter the correct (non-default) master password.

      The upgrade reports errors because it cannot access the keystore; a security service seems not to be using the correct, non-default password.

      I will attach the e-mail message from the users mailing list and the user's upgrade log file as sent in his e-mail.

      A workaround that worked for me was to change the master password of the original (old) domain to be the default master password, then run the upgrade, then change the master password to the desired, non-default value.

      1. upgradeBugMail.txt
        2 kB
        Tim Quinn
      2. users-upgrade.log
        19 kB
        Tim Quinn

        Activity

        Hide
        Tim Quinn added a comment -

        Attaching text from users's e-mail and the user's upgrade log.

        Show
        Tim Quinn added a comment - Attaching text from users's e-mail and the user's upgrade log.
        Hide
        Tim Quinn added a comment -

        Fixing a typo on the original description.

        Show
        Tim Quinn added a comment - Fixing a typo on the original description.
        Hide
        Tim Quinn added a comment -

        I have investigated this a bit, and here's what seems to be happening.

        During both a normal GlassFish start-up and the start-up during upgrade, specifying "--passwordfile -" on the command line works to collect (among other things) AS_ADMIN_MASTERPASSWORD=the-pw from stdin.

        During a normal start-up, the IdmService.postConstruct method reads the setting from stdin and sets the master password in the MasterPassword object (injected into IdmService and also injected elsewhere).

        But during the upgrade-triggered start-up, I did not see the IdmService.postConstruct ever invoked, probably because no class that's run during upgrade injects it. So, the user-entered master password is never read from stdin and is never set in MasterPassword. Later during the upgrade-triggered start-up, SecuritySupportImpl looks for (and does not find) a MasterPassword in hk2, so it uses the default master password.

        If the old domain's master password is not the default, then SecuritySupportImpl cannot access the keystore and truststore using the default, and that triggers the failure the user reported.

        This problem persists in the trunk (4.0), because the problem occurs during the start-domain --upgrade execution, not while the upgrade tool (which is now retired from the product) runs.

        A near-fix would be to @Inject IdentityManager (for which IdmService is the implementation) into SecureAdminUpgradeHelper, to make sure that the master password is read from stdin before it's needed. But that is not the complete solution because of the way SecuritySupportImpl works. It does its initialization from its constructor, not from a postConstruct method. (There are some places in the code that directly instantiate SecuritySupportImpl without using hk2). So the habitat is not injected yet. Also, during the upgrade processing, the habitat in Globals is not yet set, so the code path in SecuritySupportImpl that tries to use that does not find a habitat which it would use to look up the MasterPassword. So it just falls back and uses the default password, which fails.

        Because a complete fix lies outside just the secure admin upgrade classes, I need to let the security team get involved in this now.

        Show
        Tim Quinn added a comment - I have investigated this a bit, and here's what seems to be happening. During both a normal GlassFish start-up and the start-up during upgrade, specifying "--passwordfile -" on the command line works to collect (among other things) AS_ADMIN_MASTERPASSWORD=the-pw from stdin. During a normal start-up, the IdmService.postConstruct method reads the setting from stdin and sets the master password in the MasterPassword object (injected into IdmService and also injected elsewhere). But during the upgrade-triggered start-up, I did not see the IdmService.postConstruct ever invoked, probably because no class that's run during upgrade injects it. So, the user-entered master password is never read from stdin and is never set in MasterPassword. Later during the upgrade-triggered start-up, SecuritySupportImpl looks for (and does not find) a MasterPassword in hk2, so it uses the default master password. If the old domain's master password is not the default, then SecuritySupportImpl cannot access the keystore and truststore using the default, and that triggers the failure the user reported. This problem persists in the trunk (4.0), because the problem occurs during the start-domain --upgrade execution, not while the upgrade tool (which is now retired from the product) runs. A near-fix would be to @Inject IdentityManager (for which IdmService is the implementation) into SecureAdminUpgradeHelper, to make sure that the master password is read from stdin before it's needed. But that is not the complete solution because of the way SecuritySupportImpl works. It does its initialization from its constructor, not from a postConstruct method. (There are some places in the code that directly instantiate SecuritySupportImpl without using hk2). So the habitat is not injected yet. Also, during the upgrade processing, the habitat in Globals is not yet set, so the code path in SecuritySupportImpl that tries to use that does not find a habitat which it would use to look up the MasterPassword. So it just falls back and uses the default password, which fails. Because a complete fix lies outside just the secure admin upgrade classes, I need to let the security team get involved in this now.
        Hide
        Tim Quinn added a comment -

        It turns out there was a way to fix this by changing only the upgrade class.

        Fix checked in.

        Project: glassfish
        Repository: svn
        Revision: 60221
        Author: tjquinn
        Date: 2013-03-08 16:48:19 UTC
        Link:

        Log Message:
        ------------
        Fix for 19031.

        During an upgrade from a domain with a non-default master password, the upgrade code did not use the correct, non-default master password. Upgrade therefore failed when it could not open the keystore.

        There were two underlying causes.

        First, the MasterPassword service, which is used by SecuritySupportImpl, was not being initialized before that usage. That's because SecuritySupportImpl is not an hk2 service and does not @Inject the master password service but looks it up explicitly, so hk2 could not detect that it needed to initialize MasterPassword.

        Second, SecuritySupportImpl uses the Globals class to get the default habitat (service locator). Globals was not initialized before SecuritySupportImpl used it, so it could not have found the MasterPassword service even if that service had been initialized.

        This change resolves both problems by adding @Inject of the MasterPassword service into the hk2-managed SecureAdminConfigUpgrade class (thus making sure that MasterPassword is created and added to the service population) and initializes the default habitat in Globals if that has not already happened. So, by the time SecuritySupportImpl gains control, Globals and the MasterPassword service are both ready for it.

        Revisions:
        ----------
        60221

        Modified Paths:
        ---------------
        trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminConfigUpgrade.java

        Show
        Tim Quinn added a comment - It turns out there was a way to fix this by changing only the upgrade class. Fix checked in. Project: glassfish Repository: svn Revision: 60221 Author: tjquinn Date: 2013-03-08 16:48:19 UTC Link: Log Message: ------------ Fix for 19031. During an upgrade from a domain with a non-default master password, the upgrade code did not use the correct, non-default master password. Upgrade therefore failed when it could not open the keystore. There were two underlying causes. First, the MasterPassword service, which is used by SecuritySupportImpl, was not being initialized before that usage. That's because SecuritySupportImpl is not an hk2 service and does not @Inject the master password service but looks it up explicitly, so hk2 could not detect that it needed to initialize MasterPassword. Second, SecuritySupportImpl uses the Globals class to get the default habitat (service locator). Globals was not initialized before SecuritySupportImpl used it, so it could not have found the MasterPassword service even if that service had been initialized. This change resolves both problems by adding @Inject of the MasterPassword service into the hk2-managed SecureAdminConfigUpgrade class (thus making sure that MasterPassword is created and added to the service population) and initializes the default habitat in Globals if that has not already happened. So, by the time SecuritySupportImpl gains control, Globals and the MasterPassword service are both ready for it. Revisions: ---------- 60221 Modified Paths: --------------- trunk/main/nucleus/security/core/src/main/java/com/sun/enterprise/security/admin/cli/SecureAdminConfigUpgrade.java

          People

          • Assignee:
            Tim Quinn
            Reporter:
            Tim Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: