[
https://issues.apache.org/jira/browse/HADOOP-12076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14580010#comment-14580010
]
Larry McCay commented on HADOOP-12076:
--------------------------------------
Hi [~busbey] - thanks for the comments and review:
bq. Are we worried about how the cache gets aged off?
I don't think so - at least not in this jira. The purpose of this patch is to
complete the mechanism that should be on par with that of the
JavaKeyStoreProvider in the KeyProvider API. If we want to add a TTL or the
like then I think that should be a follow on jira as an enhancement.
bq. Since AbstractJavaKeyStore isn't thread safe, do we know what happens if
multiple instances are pointing at the same jks file?
I'm not entirely sure of the usecase that you have in mind. There are
read/write locks in this class for providing thread safety. Perhaps there are
state issues not covered properly? If so, we should file separate jiras for
them. At any rate, I assume that you question is in the context of the cache.
Multiple credential provider instances pointing at the same file should be fine
assuming that these credentials are generally rather static. The initial
usecases are primarily around the passwords that would otherwise be in config
files such as those for SSL related keystores or LDAP bind passwords, etc.
Therefore, multiple readers are largely not a problem. Now, if someone changes
any of those stored passwords the consumers of the credential provider will
either need to instantiate new providers (which the Configuration.getPassword
call does on each call anyway) or restart.
bq. Presuming the above works, how do we reconcile changes that happen to the
underlying jks against the cache?
I think this is largely answered by in the previous question. I guess if
passwords are added to the store that they will be picked up without any need
for restart or new instances - due to them not being cached. If you used the
CLI and deleted an SSL password it would still be returned by the cache until
restart or new instances (again, Configuration.getPassword isn't a problem
there). If you change the existing password to a keystore then it will probably
continue to work until you restart and try to load the certs again. In which
case, if the new password matches the keystore it will work otherwise it won't.
bq. You should do something to ensure that deleting the file means that
non-cached entries won't be returned.
That's a good idea - I'll add that additional check to ensure that the keystore
is actually gone and whether we blow up - which we probably will. Will have to
determine whether that is good or bad...
> Incomplete Cache Mechanism in CredentialProvider API
> ----------------------------------------------------
>
> Key: HADOOP-12076
> URL: https://issues.apache.org/jira/browse/HADOOP-12076
> Project: Hadoop Common
> Issue Type: Bug
> Components: security
> Reporter: Larry McCay
> Assignee: Larry McCay
> Attachments: HADOOP-12076-001.patch
>
>
> The AbstractJavaKeyStoreProvider class in the CredentialProvider API has a
> cache member variable and interrogation of it during access but does not
> populate it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
