[
https://issues.apache.org/jira/browse/ZOOKEEPER-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Shelukhin updated ZOOKEEPER-2451:
----------------------------------------
Description:
Is there (or could there be) a way to set up security for ZK client that
doesn't involve calls like {noformat}
System.setProperty(ZooKeeperSaslClient.LOGIN_CONTEXT_NAME_KEY,
SASL_LOGIN_CONTEXT_NAME);
{noformat}?
I was looking at an unrelated security configuration issue and stumbled upon
this pattern; we use (at least) 2 ZK connections from the same process, that
(for now) use the same config but different context names, one of which is in a
library out of our control. Unless I'm missing something with this pattern it
seems extremely brittle. Or unless there's an alternative approach already; if
there is, hadoop-common and hive don't use it atm, old approach seems prevalent.
There should be an approach that is at least slightly more solid, like say
public globals... maybe even threadlocals!
was:
Is there (or could there be) a way to set up security for ZK client that
doesn't involve calls like {noformat}
System.setProperty(ZooKeeperSaslClient.LOGIN_CONTEXT_NAME_KEY,
SASL_LOGIN_CONTEXT_NAME);
{noformat}?
I was looking at an unrelated security configuration issue and stumbled upon
this pattern; we use (at least) 2 ZK connections from the same process, that
(for now) use the same config but different context name, one of which is in a
library out of our control. Unless I'm missing something with this pattern it
seems extremely brittle. Or unless there's an alternative approach already; if
there is, hadoop-common and hive don't use it atm, old approach seems prevalent.
There should be an approach that is at least slightly more solid, like say
public globals... maybe even threadlocals!
> do not make use of system properties for security configuration
> ---------------------------------------------------------------
>
> Key: ZOOKEEPER-2451
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2451
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Sergey Shelukhin
>
> Is there (or could there be) a way to set up security for ZK client that
> doesn't involve calls like {noformat}
> System.setProperty(ZooKeeperSaslClient.LOGIN_CONTEXT_NAME_KEY,
> SASL_LOGIN_CONTEXT_NAME);
> {noformat}?
> I was looking at an unrelated security configuration issue and stumbled upon
> this pattern; we use (at least) 2 ZK connections from the same process, that
> (for now) use the same config but different context names, one of which is in
> a library out of our control. Unless I'm missing something with this pattern
> it seems extremely brittle. Or unless there's an alternative approach
> already; if there is, hadoop-common and hive don't use it atm, old approach
> seems prevalent.
> There should be an approach that is at least slightly more solid, like say
> public globals... maybe even threadlocals!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
