jclouds-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graeme Miller (JIRA)" <j...@apache.org>
Subject [jira] [Created] (JCLOUDS-1319) CredentialStore leaking
Date Fri, 07 Jul 2017 15:01:00 GMT
Graeme Miller created JCLOUDS-1319:

             Summary: CredentialStore leaking
                 Key: JCLOUDS-1319
                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1319
             Project: jclouds
          Issue Type: Bug
            Reporter: Graeme Miller
            Priority: Critical

The class CredentialStoreModule provides a CredentialStore to various ComputeServices through
the method provideCredentialStore. provideCredentialStore creates the map using a backing
map called BACKING that is defined statically in CredentialStoreModule. What this means is
that although we are calling provideCredentialStore on the creation of each ComputeService,
we are sharing a map over ComputeServices. This may very well be a deliberate design decision,
I am not sure, but it is important to the bug I am seeing.

An issue arrises due to the class GetLoginForProviderFromPropertiesAndStoreCredentialsOrReturnNull.
This class is used to provide default LoginCredentials when creating a ComputeService. It
checks the CredentialStore, and if there is nothing in it, it will create the LoginCredentials
and store them in the CredentialStore with a key called 'image'. The problem is that the class
GetLoginForProviderFromPropertiesAndStoreCredentialsOrReturnNull is used by multiple providers
so they all use the key 'image'. 

So, if you create a ComputeService for Azure ARM and then later one for AWS it will use the
LoginCredentials created for Azure ARM in the AWS ComputeService. This causes an issue as
these LoginCredentials are used in EC2PopulateDefaultLoginCredentialsForImageStrategy to get
the default user to log in as. Azure ARM chooses jclouds as the default user, whereas AWS
chooses root. If you therefore create the Azure context and then the AWS context you will
end up using the wrong ssh user for AWS.

*) don't share CredentialStore across ComputerServices
*) Store the LoginCredentials in the map against a key with the provider name in it. 
*) Don't store the LoginCredentials in the map at all, create it every time

This message was sent by Atlassian JIRA

View raw message