[
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15474353#comment-15474353
]
Michael Han commented on ZOOKEEPER-1045:
----------------------------------------
Re reconfig and 1045:
bq. But what are you saying, further weight to not use zoo.cfg? Or is there a
specific issue you think needs to be addressed directly.
The specific issue I think, which was pointed out by Alex is that zoo.cfg does
not contain up to date server list during reconfig, so if a server that's
perfect valid ask to join quorum the request will be denied with current auth
mechanism because quorum peer will not find the server on zoo.cfg.
bq. I think this has to be restricted at the reconfig command execution side
rather than FLE, probably ZOOKEEPER-2014 jira will help to resolve this
problem, am I missing anything?
ZOOKEEPER-2014 will hopefully ensure that all servers participating reconfig
are valid (because only admin or admin equivalent parties can issue the
command, if an admin is rogue, all bets are off), and with this it should be
good enough from security point of view such that we can skip the downstream
auth checks on these servers. The problem here is, the downstream logic (auth
check in FLE) has to be aware of that these new servers are from reconfig so it
can skip the checks, otherwise these servers will fail auth check (with current
logic that solely rely on zoo.cfg that does not contain up to date server info,
unless we do something different).
I see two solutions here:
* When in reconfig mode, skip auth checks for quorum peers. Not sure how
exactly we would do this, but I imagine we could possibly have some flags
associated with the reconfig context and pass that around.
* Or, we don't treat reconfig as a special case, instead, we still do auth
checks of quorum peers. To do that, we need up to date server info, which we
should read from the zoo.cfg.dynamic files.
> Support Quorum Peer mutual authentication via SASL
> --------------------------------------------------
>
> Key: ZOOKEEPER-1045
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> Project: ZooKeeper
> Issue Type: New Feature
> Components: server
> Reporter: Eugene Koontz
> Assignee: Rakesh R
> Priority: Critical
> Fix For: 3.4.10, 3.5.3
>
> Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch,
> 1045_failing_phunt.tar.gz, HOST_RESOLVER-ZK-1045.patch,
> TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt,
> ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045-00.patch,
> ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf,
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch,
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch,
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch,
> ZOOKEEPER-1045TestValidationDesign.pdf
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers.
> This bug, on the other hand, is for authentication among quorum peers.
> Hopefully much of the work done on SASL integration with Zookeeper for
> ZOOKEEPER-938 can be used as a foundation for this enhancement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
