[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15617246#comment-15617246
 ] 

Eugene Koontz commented on ZOOKEEPER-1045:
--

I left a few minor comments on the reviewboard here:

https://reviews.apache.org/r/47354/#comment223707

I will try to get up to speed with the discussion thus far in the JIRA and 
hopefully have something else to add.

> 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: quorum, security
>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, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Sep-25.pdf, 
> TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt, 
> ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045 Test Plan.pdf, 
> 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-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, 
> org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.testRollingUpgrade.log
>
>
> 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.
> Review board: https://reviews.apache.org/r/47354/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419069#comment-15419069
 ] 

Eugene Koontz edited comment on ZOOKEEPER-1045 at 8/12/16 4:12 PM:
---

Thank you [~rakeshr] for the correction - I'm now using the latest, correct 
patch. 


was (Author: ekoontz):
Thank you ~rakeshr for the correction - I'm now using the latest, correct 
patch. 

> 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.5.3, 3.4.10
>
> 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)

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15419069#comment-15419069
 ] 

Eugene Koontz commented on ZOOKEEPER-1045:
--

Thank you ~rakeshr for the correction - I'm now using the latest, correct 
patch. 

> 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.5.3, 3.4.10
>
> 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)

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15417969#comment-15417969
 ] 

Eugene Koontz commented on ZOOKEEPER-1045:
--

Coming into this late and getting up to speed - I hope to have a look at the 
patch in the next few days. I've successfully patched against branch-3.4 with 
both patches as follows:

{code}
git checkout remotes/upstream/branch-3.4
git log -1
commit 82ea70cc128336411ff83f1fd177f9a62aa1e14e
Author: Flavio Paiva Junqueira 
Date:   Wed Aug 10 14:11:48 2016 +

Fix command handling in the C client shell (phunt via fpj)
{code}

Then I applied the two most recent patches:
{code}
cat 0001-ZOOKEEPER-1045-br-3-4.patch | patch -p1
cat HOST_RESOLVER-ZK-1045.patch | patch -p1
{code}

both of which applied without errors or warnings.

I'm running {{ant test}} now. Do those steps get me up to date with the latest 
development on this issue?

Thanks, Eugene

> 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.5.3, 3.4.10
>
> 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)

[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15297160#comment-15297160
 ] 

Eugene Koontz commented on ZOOKEEPER-1467:
--

Hi Arshad,
Sure, thanks for the reminder. Should be able to submit tomorrow.
-Eugene

> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
>Reporter: Laxman
>Assignee: Eugene Koontz
>Priority: Critical
>  Labels: Security, client, kerberos, sasl
> Fix For: 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new 
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like 
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15144240#comment-15144240
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi  Devendra,

Are you sure you are kerberos-authenticated? Can you post the output of running 
klist before starting hbase shell? Also can you try running zkCli.sh and see if 
you can access the znode /hbase-secure/replication/peers znode?

-Eugene

> Client uses session before SASL authentication complete
> ---
>
> Key: ZOOKEEPER-1437
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.3
>Reporter: Thomas Weise
>Assignee: Eugene Koontz
> Fix For: 3.4.4, 3.5.0
>
> Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> getXidCallHierarchy.png
>
>
> Found issue in the context of hbase region server startup, but can be 
> reproduced w/ zkCli alone.
> getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
> not expected behavior when the client is configured to use SASL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15145774#comment-15145774
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Ok, I think I see the problem. Your principle is "hbase-tdclus...@dev.com". The 
"@DEV.COM" is ignored for the purpose of authorization, but "hbase-tdcluster" 
!= "hbase", so you don't have any permissions for the /hbase zknode.

> Client uses session before SASL authentication complete
> ---
>
> Key: ZOOKEEPER-1437
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.3
>Reporter: Thomas Weise
>Assignee: Eugene Koontz
> Fix For: 3.4.4, 3.5.0
>
> Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
> getXidCallHierarchy.png
>
>
> Found issue in the context of hbase region server startup, but can be 
> reproduced w/ zkCli alone.
> getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
> not expected behavior when the client is configured to use SASL.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2159) Pluggable SASL Authentication

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14516629#comment-14516629
 ] 

Eugene Koontz commented on ZOOKEEPER-2159:
--

Yuliya,
I published a review on the review board - have not had a chance to try out 
kerberos yet - will try that soon; planning on it tomorrow.
-Eugene

 Pluggable SASL Authentication
 -

 Key: ZOOKEEPER-2159
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159
 Project: ZooKeeper
  Issue Type: Improvement
  Components: java client, server
Reporter: Yuliya Feldman
Assignee: Yuliya Feldman
 Attachments: PluggableZookeeperAuthentication (1).pdf, 
 PluggableZookeeperAuthentication.pdf


 Today SASLAuthenticationProvider is used for all SASL based authentications 
 which creates some if/else statements in ZookeeperSaslClient and 
 ZookeeperSaslServer code with just Kerberos and Digest.
 We want to use yet another different SASL based authentication and adding one 
 more if/else with some code specific just to that new way does not make 
 much sense.
 Proposal is to allow to plug custom SASL Authentication mechanism(s) without  
 further changes in Zookeeper code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2159) Pluggable SASL Authentication

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511039#comment-14511039
 ] 

Eugene Koontz commented on ZOOKEEPER-2159:
--

Hi Yuliya,
I have had a chance to look at the overall design on the review board and it 
looks good. As you said, it makes sense to create an abstract AuthMethod which 
can be subclassed (e.g. to DIGEST-MD5, KRB5, etc) rather than having a bunch of 
if ..else .. blocks as we do currently. I would like to test it with my own 
local kerberos setup and hopefully have some more helpful detailed comments 
which I will put in the review board this weekend.

 Pluggable SASL Authentication
 -

 Key: ZOOKEEPER-2159
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159
 Project: ZooKeeper
  Issue Type: Improvement
  Components: java client, server
Reporter: Yuliya Feldman
Assignee: Yuliya Feldman
 Attachments: PluggableZookeeperAuthentication (1).pdf, 
 PluggableZookeeperAuthentication.pdf


 Today SASLAuthenticationProvider is used for all SASL based authentications 
 which creates some if/else statements in ZookeeperSaslClient and 
 ZookeeperSaslServer code with just Kerberos and Digest.
 We want to use yet another different SASL based authentication and adding one 
 more if/else with some code specific just to that new way does not make 
 much sense.
 Proposal is to allow to plug custom SASL Authentication mechanism(s) without  
 further changes in Zookeeper code.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-703) GSoC 2010: ZooKeeper DNS Server

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14287077#comment-14287077
 ] 

Eugene Koontz commented on ZOOKEEPER-703:
-

I agree, really cool! Hope someone can work on it.

 GSoC 2010: ZooKeeper DNS Server
 ---

 Key: ZOOKEEPER-703
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-703
 Project: ZooKeeper
  Issue Type: Wish
Reporter: Henry Robinson
  Labels: gsoc, mentor

 ZooKeeper DNS Server
 Possible Mentor
 Henry Robinson (henry at apache dot org)
 Requirements
 Java or Python or C
 Description
 Although ZooKeeper is primarily used for co-ordination of distributed 
 processes, its consistency semantics means that it's a good candidate for 
 serving small (key,value) records as well. The Domain Name Service has 
 similar requirements, raising the interesting question of whether ZooKeeper 
 would be a capable DNS server for your local network. One intriguing 
 possibility is having versioned DNS records, such that known-good 
 configurations can be stored and rolled back to in the case of an issue. If 
 this versioning primitive proves to be useful, it's easy to imagine other 
 types of configuration that could be stored.
 This project would involve designing and building an RFC-1035 compliant DNS 
 server and performing a detailed performance study against an already 
 existant simple DNS server like tinydns.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13780101#comment-13780101
 ] 

Eugene Koontz commented on ZOOKEEPER-1759:
--

Yuliya, thanks for the explanation of the problem that Flavio found, your new 
patch looks good.  It's good that the tests run in a random order; seems to 
shake out bugs that otherwise would not be seen. 

I'm not entirely satisfied with the new name letAnySaslUserDoX, it sounds 
awkward, but it's good enough for now.

 Adding ability to allow READ operations for authenticated users,  versus 
 keeping ACLs wide open for READ
 

 Key: ZOOKEEPER-1759
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1759
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.5
 Environment: Java, SASL authentication, security
Reporter: Yuliya Feldman
 Fix For: 3.5.0

 Attachments: 
 TEST-org.apache.zookeeper.test.SaslAuthDesignatedClientTest.txt, 
 ZOOKEEPER-1759-1.patch, ZOOKEEPER-1759-1.patch, ZOOKEEPER-1759.patch, 
 ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch


 Today when using SASLAuthenticationProvider to authenticate Zookeeper Clients 
 access to the data based on ACLS set on znodes there is no other choice but 
 to set READ ACLs to be world, anyone with the way how 
 {code:java}
 public boolean matches(String id,String aclExpr)
 {code}
 is currently implemented. It means that any unauthenticated user can read the 
 data when application needs to make sure that not only creator of a znode can 
 read the content.
 Proposal is to introduce new property: zookeeper.readUser that if incoming 
 id matches to the value of that property it will be allowed to proceed in 
 match method. 
 So creator of a znode instead of 
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
 {code}
 will need to do
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, new Id(sasl, anyone));
 {code}
 Assuming that value of zookeeper.readUser property was anyone.
 This way at least READ access on corresponding znode has to be authenticated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777686#comment-13777686
 ] 

Eugene Koontz commented on ZOOKEEPER-1759:
--

Looks good to me, Yuliya. +1 (nonbinding).

 Adding ability to allow READ operations for authenticated users,  versus 
 keeping ACLs wide open for READ
 

 Key: ZOOKEEPER-1759
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1759
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.5
 Environment: Java, SASL authentication, security
Reporter: Yuliya Feldman
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch, 
 ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch


 Today when using SASLAuthenticationProvider to authenticate Zookeeper Clients 
 access to the data based on ACLS set on znodes there is no other choice but 
 to set READ ACLs to be world, anyone with the way how 
 {code:java}
 public boolean matches(String id,String aclExpr)
 {code}
 is currently implemented. It means that any unauthenticated user can read the 
 data when application needs to make sure that not only creator of a znode can 
 read the content.
 Proposal is to introduce new property: zookeeper.readUser that if incoming 
 id matches to the value of that property it will be allowed to proceed in 
 match method. 
 So creator of a znode instead of 
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
 {code}
 will need to do
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, new Id(sasl, anyone));
 {code}
 Assuming that value of zookeeper.readUser property was anyone.
 This way at least READ access on corresponding znode has to be authenticated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777697#comment-13777697
 ] 

Eugene Koontz commented on ZOOKEEPER-1759:
--

Well, I forgot, there is the matter of the name of the property 
zookeeper.readUser as we discussed with regard to my question #1 above. 
zookeeper.letAnySaslUserDoX perhaps?

 Adding ability to allow READ operations for authenticated users,  versus 
 keeping ACLs wide open for READ
 

 Key: ZOOKEEPER-1759
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1759
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.5
 Environment: Java, SASL authentication, security
Reporter: Yuliya Feldman
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch, 
 ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch


 Today when using SASLAuthenticationProvider to authenticate Zookeeper Clients 
 access to the data based on ACLS set on znodes there is no other choice but 
 to set READ ACLs to be world, anyone with the way how 
 {code:java}
 public boolean matches(String id,String aclExpr)
 {code}
 is currently implemented. It means that any unauthenticated user can read the 
 data when application needs to make sure that not only creator of a znode can 
 read the content.
 Proposal is to introduce new property: zookeeper.readUser that if incoming 
 id matches to the value of that property it will be allowed to proceed in 
 match method. 
 So creator of a znode instead of 
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
 {code}
 will need to do
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, new Id(sasl, anyone));
 {code}
 Assuming that value of zookeeper.readUser property was anyone.
 This way at least READ access on corresponding znode has to be authenticated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776531#comment-13776531
 ] 

Eugene Koontz commented on ZOOKEEPER-1759:
--

Hi Camille, thanks for bringing this to my attention. Yuliya, two questions:

1) I don't think the property name zookeeper.readUser is meaningful - in this 
code that you added to matches():

{code}
String readAccessUser = System.getProperty(zookeeper.readUser);
if ( readAccessUser != null  aclExpr.equals(readAccessUser)) {
  return true;
}
{code}

Above, there is no a check for whether the user wants to specifically read as 
opposed to any other action. 

For example, if a) and b) are true:

a) I add an ACL: ((Perms.READ | Perms.WRITE), new Id(sasl, anyone))

and 

b) the property zookeeper.readUser is set to anyone

then this user can read *and* write to the node. So it seems like you could 
call the property zookeeper.x-User just as well: it's the ACL on the node, 
not the property, that determines what set of actions x that the user defined 
by this property can do.

2. I'm not sure what this change adds any new authorization restrictions - it's 
seems the same as simply making a node world-readable. What if a user is not 
SASL-authenticated? Won't the new code that you added in matches():

{code}
String readAccessUser = System.getProperty(zookeeper.readUser);
if ( readAccessUser != null  aclExpr.equals(readAccessUser)) {
  return true;
}
{code}

simply return true regardless of whether the client is SASL-authenticated or 
not, if a given node is set to ACL(Perms.READ, new Id(sasl, anyone), and 
zookeeper.readUser is set to anyone?

I might be wrong - but either way, the question could be resolved with an 
additional unit test, which clarifies what the permissions are of a 
non-SASL-authenticated user when the user attempts to read a node which has:

a) ACL(Perms.READ, new Id(sasl, anyone)
b) has no other permissions (e.g. not world-readable).


-Eugene

 Adding ability to allow READ operations for authenticated users,  versus 
 keeping ACLs wide open for READ
 

 Key: ZOOKEEPER-1759
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1759
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.5
 Environment: Java, SASL authentication, security
Reporter: Yuliya Feldman
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch, 
 ZOOKEEPER-1759.patch


 Today when using SASLAuthenticationProvider to authenticate Zookeeper Clients 
 access to the data based on ACLS set on znodes there is no other choice but 
 to set READ ACLs to be world, anyone with the way how 
 {code:java}
 public boolean matches(String id,String aclExpr)
 {code}
 is currently implemented. It means that any unauthenticated user can read the 
 data when application needs to make sure that not only creator of a znode can 
 read the content.
 Proposal is to introduce new property: zookeeper.readUser that if incoming 
 id matches to the value of that property it will be allowed to proceed in 
 match method. 
 So creator of a znode instead of 
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
 {code}
 will need to do
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, new Id(sasl, anyone));
 {code}
 Assuming that value of zookeeper.readUser property was anyone.
 This way at least READ access on corresponding znode has to be authenticated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776799#comment-13776799
 ] 

Eugene Koontz commented on ZOOKEEPER-1759:
--

Hi Yuliya,
Regarding #2, yes, I think you are right: a non-SASL-authenticated user will 
not have a authId for the SASL AuthenticationProvider, so the matches() will 
not be called, and the user will not be granted access, which is expected and 
correct behavior. So thanks for correcting me on this.

I still think it would be good to test this feature with a 
non-SASL-authenticated user to test that this behavior is working as expected, 
however. Your test is good but only tests a SASL authenticated user.

 Adding ability to allow READ operations for authenticated users,  versus 
 keeping ACLs wide open for READ
 

 Key: ZOOKEEPER-1759
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1759
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.5
 Environment: Java, SASL authentication, security
Reporter: Yuliya Feldman
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1759.patch, ZOOKEEPER-1759.patch, 
 ZOOKEEPER-1759.patch


 Today when using SASLAuthenticationProvider to authenticate Zookeeper Clients 
 access to the data based on ACLS set on znodes there is no other choice but 
 to set READ ACLs to be world, anyone with the way how 
 {code:java}
 public boolean matches(String id,String aclExpr)
 {code}
 is currently implemented. It means that any unauthenticated user can read the 
 data when application needs to make sure that not only creator of a znode can 
 read the content.
 Proposal is to introduce new property: zookeeper.readUser that if incoming 
 id matches to the value of that property it will be allowed to proceed in 
 match method. 
 So creator of a znode instead of 
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
 {code}
 will need to do
 {code:java}
 ACL acl1 = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE, 
 Ids.AUTH_IDS);
 ACL acl2 = new ACL(Perms.READ, new Id(sasl, anyone));
 {code}
 Assuming that value of zookeeper.readUser property was anyone.
 This way at least READ access on corresponding znode has to be authenticated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592756#comment-13592756
 ] 

Eugene Koontz commented on ZOOKEEPER-1657:
--

Thanks for reporting back Gunnar! Good to hear that this patch fixes the 
hotspot. 

 Increased CPU usage by unnecessary SASL checks
 --

 Key: ZOOKEEPER-1657
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.5
Reporter: Gunnar Wagenknecht
  Labels: performance
 Fix For: 3.5.0, 3.4.6

 Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, 
 ZOOKEEPER-1657.patch, zookeeper-hotspot-gone.png, zookeeper-hotspot.png


 I did some profiling in one of our Java environments and found an interesting 
 footprint in ZooKeeper. The SASL support seems to trigger a lot times on the 
 client although it's not even in use.
 Is there a switch to disable SASL completely?
 The attached screenshot shows a 10-minute profiling session on one of our 
 production Jetty servers. The Jetty server handles ~1k web requests per 
 minute. The average response time per web request is a few milli seconds. The 
 profiling was performed on a machine running for 24h. 
 We noticed a significant CPU increase on our servers when deploying an update 
 from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The 
 screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65% 
 are spend in ZooKeeper. 
 A few notes/thoughts:
 * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to 
 be the culprit
 * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be 
 called very often?
 * There is quite a bit reflection involved in 
 {{java.security.AccessController.doPrivileged}}
 * No security manager is active in the JVM: I tend to place an if-check in 
 the code before calling {{AccessController.doPrivileged}}. When no SM is 
 installed, the runnable can be called directly which safes cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13592757#comment-13592757
 ] 

Eugene Koontz commented on ZOOKEEPER-1657:
--

Regarding: Please justify why no new tests are needed for this patch.

This is an optimization that avoids some unnecessary code execution. No bugs 
are fixed and no new behavior is introduced that would require additional 
testing.

 Increased CPU usage by unnecessary SASL checks
 --

 Key: ZOOKEEPER-1657
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.5
Reporter: Gunnar Wagenknecht
  Labels: performance
 Fix For: 3.5.0, 3.4.6

 Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, 
 ZOOKEEPER-1657.patch, zookeeper-hotspot-gone.png, zookeeper-hotspot.png


 I did some profiling in one of our Java environments and found an interesting 
 footprint in ZooKeeper. The SASL support seems to trigger a lot times on the 
 client although it's not even in use.
 Is there a switch to disable SASL completely?
 The attached screenshot shows a 10-minute profiling session on one of our 
 production Jetty servers. The Jetty server handles ~1k web requests per 
 minute. The average response time per web request is a few milli seconds. The 
 profiling was performed on a machine running for 24h. 
 We noticed a significant CPU increase on our servers when deploying an update 
 from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The 
 screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65% 
 are spend in ZooKeeper. 
 A few notes/thoughts:
 * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to 
 be the culprit
 * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be 
 called very often?
 * There is quite a bit reflection involved in 
 {{java.security.AccessController.doPrivileged}}
 * No security manager is active in the JVM: I tend to place an if-check in 
 the code before calling {{AccessController.doPrivileged}}. When no SM is 
 installed, the runnable can be called directly which safes cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1657:
-

Attachment: ZOOKEEPER-1657.patch

Client checks system property {{zookeeper.client.sasl}} before creating SASL 
authentication object to reduce wasted time later in 
ClientCnxn$SendThread.clientTunneledAuthenticationInProgress().

 Increased CPU usage by unnecessary SASL checks
 --

 Key: ZOOKEEPER-1657
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.5
Reporter: Gunnar Wagenknecht
  Labels: performance
 Attachments: ZOOKEEPER-1657.patch, zookeeper-hotspot.png


 I did some profiling in one of our Java environments and found an interesting 
 footprint in ZooKeeper. The SASL support seems to trigger a lot times on the 
 client although it's not even in use.
 Is there a switch to disable SASL completely?
 The attached screenshot shows a 10-minute profiling session on one of our 
 production Jetty servers. The Jetty server handles ~1k web requests per 
 minute. The average response time per web request is a few milli seconds. The 
 profiling was performed on a machine running for 24h. 
 We noticed a significant CPU increase on our servers when deploying an update 
 from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The 
 screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65% 
 are spend in ZooKeeper. 
 A few notes/thoughts:
 * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to 
 be the culprit
 * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be 
 called very often?
 * There is quite a bit reflection involved in 
 {{java.security.AccessController.doPrivileged}}
 * No security manager is installed; I tend to place an if-check in the code 
 before calling {{AccessController.doPrivileged}}. When no SM is installed, 
 the runnable can be called directly which safes cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13590795#comment-13590795
 ] 

Eugene Koontz commented on ZOOKEEPER-1657:
--

Hi Gunnar,
Thanks for providing this profiling data. I wonder if this patch will improve 
your profiling results?
-Eugene

 Increased CPU usage by unnecessary SASL checks
 --

 Key: ZOOKEEPER-1657
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.5
Reporter: Gunnar Wagenknecht
  Labels: performance
 Attachments: ZOOKEEPER-1657.patch, zookeeper-hotspot.png


 I did some profiling in one of our Java environments and found an interesting 
 footprint in ZooKeeper. The SASL support seems to trigger a lot times on the 
 client although it's not even in use.
 Is there a switch to disable SASL completely?
 The attached screenshot shows a 10-minute profiling session on one of our 
 production Jetty servers. The Jetty server handles ~1k web requests per 
 minute. The average response time per web request is a few milli seconds. The 
 profiling was performed on a machine running for 24h. 
 We noticed a significant CPU increase on our servers when deploying an update 
 from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The 
 screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65% 
 are spend in ZooKeeper. 
 A few notes/thoughts:
 * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to 
 be the culprit
 * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be 
 called very often?
 * There is quite a bit reflection involved in 
 {{java.security.AccessController.doPrivileged}}
 * No security manager is installed; I tend to place an if-check in the code 
 before calling {{AccessController.doPrivileged}}. When no SM is installed, 
 the runnable can be called directly which safes cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1657:
-

Attachment: ZOOKEEPER-1657.patch

Add new zookeeper.sasl.client system property. True by default; set to false 
to disable SASL on client.

 Increased CPU usage by unnecessary SASL checks
 --

 Key: ZOOKEEPER-1657
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.5
Reporter: Gunnar Wagenknecht
  Labels: performance
 Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, 
 zookeeper-hotspot.png


 I did some profiling in one of our Java environments and found an interesting 
 footprint in ZooKeeper. The SASL support seems to trigger a lot times on the 
 client although it's not even in use.
 Is there a switch to disable SASL completely?
 The attached screenshot shows a 10-minute profiling session on one of our 
 production Jetty servers. The Jetty server handles ~1k web requests per 
 minute. The average response time per web request is a few milli seconds. The 
 profiling was performed on a machine running for 24h. 
 We noticed a significant CPU increase on our servers when deploying an update 
 from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The 
 screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65% 
 are spend in ZooKeeper. 
 A few notes/thoughts:
 * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to 
 be the culprit
 * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be 
 called very often?
 * There is quite a bit reflection involved in 
 {{java.security.AccessController.doPrivileged}}
 * No security manager is active in the JVM: I tend to place an if-check in 
 the code before calling {{AccessController.doPrivileged}}. When no SM is 
 installed, the runnable can be called directly which safes cycles.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1547) Test robustness of client using SASL in the presence of dropped requests

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1547:
-

Description: 
ZK clients send SASL packets to ZK servers as request packets. However, what if 
the server does not responds to the client's SASL packets with responses? In 
this scenario, the server does not actually close the connection to the client, 
it simply fails to respond to SASL requests. Make sure the client can cope with 
this behavior.

Background:

In ZOOKEEPER-1437, Ben writes: 

[I]t would be great to add a test that simply drops responses to clients 
without closing connections.

https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13447477page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447477

Also in ZOOKEEPER-1437 Rakesh writes: I could see 
DisconnectableZooKeeper.disconnect() has network delays/partition simulation 
logic.

https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13445704page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13445704



  was:
ZK clients send SASL packets to ZK servers as request packets. However, what if 
the server does not responds to the client's SASL packets with responses? The 
server does not actually close the connection to the client, it simply fails to 
respond to SASL requests. Make sure the client can cope with this behavior.

Background:

In ZOOKEEPER-1437, Ben writes: 

[I]t would be great to add a test that simply drops responses to clients 
without closing connections.

https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13447477page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447477

Also in ZOOKEEPER-1437 Rakesh writes: I could see 
DisconnectableZooKeeper.disconnect() has network delays/partition simulation 
logic.

https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13445704page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13445704




 Test robustness of client using SASL in the presence of dropped requests
 

 Key: ZOOKEEPER-1547
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1547
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Eugene Koontz

 ZK clients send SASL packets to ZK servers as request packets. However, what 
 if the server does not responds to the client's SASL packets with responses? 
 In this scenario, the server does not actually close the connection to the 
 client, it simply fails to respond to SASL requests. Make sure the client can 
 cope with this behavior.
 Background:
 In ZOOKEEPER-1437, Ben writes: 
 [I]t would be great to add a test that simply drops responses to clients 
 without closing connections.
 https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13447477page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447477
 Also in ZOOKEEPER-1437 Rakesh writes: I could see 
 DisconnectableZooKeeper.disconnect() has network delays/partition simulation 
 logic.
 https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13445704page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13445704

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1561) Zookeeper client may hang on a server restart

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490117#comment-13490117
 ] 

Eugene Koontz commented on ZOOKEEPER-1561:
--

It's a good time to revisit this now that ZOOKEEPER-1560 is fixed. 

 Zookeeper client may hang on a server restart
 -

 Key: ZOOKEEPER-1561
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1561
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.5.0
Reporter: Jacky007
 Fix For: 3.5.0


 In the doIO method of ClientCnxnSocketNIO
 {noformat}
  if (p != null) {
 outgoingQueue.removeFirstOccurrence(p);
 updateLastSend();
 if ((p.requestHeader != null) 
 (p.requestHeader.getType() != OpCode.ping) 
 (p.requestHeader.getType() != OpCode.auth)) {
 p.requestHeader.setXid(cnxn.getXid());
 }
 p.createBB();
 ByteBuffer pbb = p.bb;
 sock.write(pbb);
 if (!pbb.hasRemaining()) {
 sentCount++;
 if (p.requestHeader != null
  p.requestHeader.getType() != OpCode.ping
  p.requestHeader.getType() != OpCode.auth) {
 pending.add(p);
 }
 }
 {noformat}
 When the sock.write(pbb) method throws an exception, the packet will not be 
 cleanup(not in outgoingQueue nor in pendingQueue). If the client wait for it, 
 it will wait forever...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13483888#comment-13483888
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Jordan,

What version of Java are you using to run the Java client? If it's Java 7, your 
problem in fact might be ZOOKEEPER-1550.

-Eugene

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-107) Allow dynamic changes to server cluster membership

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13476603#comment-13476603
 ] 

Eugene Koontz commented on ZOOKEEPER-107:
-

I was thinking the same thing, Ted. Thanks for investigating.

 Allow dynamic changes to server cluster membership
 --

 Key: ZOOKEEPER-107
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Reporter: Patrick Hunt
Assignee: Alexander Shraer
 Fix For: 3.5.0

 Attachments: SimpleAddition.rtf, zkreconfig-usenixatc-final.pdf, 
 ZOOKEEPER-107-14-Oct.patch, ZOOKEEPER-107-15-Oct.patch, 
 ZOOKEEPER-107-15-Oct-ver1.patch, ZOOKEEPER-107-15-Oct-ver2.patch, 
 ZOOKEEPER-107-15-Oct-ver3.patch, ZOOKEEPER-107-1-Mar.patch, 
 ZOOKEEPER-107-20-July.patch, ZOOKEEPER-107-21-July.patch, 
 ZOOKEEPER-107-22-Apr.patch, ZOOKEEPER-107-23-SEP.patch, 
 ZOOKEEPER-107-28-Feb.patch, ZOOKEEPER-107-28-Feb.patch, 
 ZOOKEEPER-107-29-Feb.patch, ZOOKEEPER-107-3-Oct.patch, 
 ZOOKEEPER-107-Aug-20.patch, ZOOKEEPER-107-Aug-20-ver1.patch, 
 ZOOKEEPER-107-Aug-25.patch, zookeeper-3.4.0.jar, zookeeper-dev-fatjar.jar, 
 zookeeper-reconfig-sep11.patch, zookeeper-reconfig-sep12.patch, 
 zoo_replicated1.cfg, zoo_replicated1.members


 Currently cluster membership is statically defined, adding/removing hosts 
 to/from the server cluster dynamically needs to be supported.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1561) Zookeeper client may hang on a server restart

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13475895#comment-13475895
 ] 

Eugene Koontz commented on ZOOKEEPER-1561:
--

I'd like to help with this if I can - first step would be a unit test that 
exposes it. If I understand from @Jacky007's description, I think that the test 
would be:

1. Start a client and server
2. Client waits till server comes up.
3. Stop the server.
4. Client sends a packet to the server (e.g. get /).
5. Restart the server.

Client should hang at step 4. Test should detect the hang somehow and fail the 
test.

 Zookeeper client may hang on a server restart
 -

 Key: ZOOKEEPER-1561
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1561
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.5.0
Reporter: Jacky007
 Fix For: 3.5.0


 In the doIO method of ClientCnxnSocketNIO
 {noformat}
  if (p != null) {
 outgoingQueue.removeFirstOccurrence(p);
 updateLastSend();
 if ((p.requestHeader != null) 
 (p.requestHeader.getType() != OpCode.ping) 
 (p.requestHeader.getType() != OpCode.auth)) {
 p.requestHeader.setXid(cnxn.getXid());
 }
 p.createBB();
 ByteBuffer pbb = p.bb;
 sock.write(pbb);
 if (!pbb.hasRemaining()) {
 sentCount++;
 if (p.requestHeader != null
  p.requestHeader.getType() != OpCode.ping
  p.requestHeader.getType() != OpCode.auth) {
 pending.add(p);
 }
 }
 {noformat}
 When the sock.write(pbb) method throws an exception, the packet will not be 
 cleanup(not in outgoingQueue nor in pendingQueue). If the client wait for it, 
 it will wait forever...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1561) Zookeeper client may hang on a server restart

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13475903#comment-13475903
 ] 

Eugene Koontz commented on ZOOKEEPER-1561:
--

I should say in my last sentence above, client *will* hang, if bug exists - 
client should clearly not hang if client code is functioning correctly.

 Zookeeper client may hang on a server restart
 -

 Key: ZOOKEEPER-1561
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1561
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.5.0
Reporter: Jacky007
 Fix For: 3.5.0


 In the doIO method of ClientCnxnSocketNIO
 {noformat}
  if (p != null) {
 outgoingQueue.removeFirstOccurrence(p);
 updateLastSend();
 if ((p.requestHeader != null) 
 (p.requestHeader.getType() != OpCode.ping) 
 (p.requestHeader.getType() != OpCode.auth)) {
 p.requestHeader.setXid(cnxn.getXid());
 }
 p.createBB();
 ByteBuffer pbb = p.bb;
 sock.write(pbb);
 if (!pbb.hasRemaining()) {
 sentCount++;
 if (p.requestHeader != null
  p.requestHeader.getType() != OpCode.ping
  p.requestHeader.getType() != OpCode.auth) {
 pending.add(p);
 }
 }
 {noformat}
 When the sock.write(pbb) method throws an exception, the packet will not be 
 cleanup(not in outgoingQueue nor in pendingQueue). If the client wait for it, 
 it will wait forever...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1560) Zookeeper client hangs on creation of large nodes

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13475085#comment-13475085
 ] 

Eugene Koontz commented on ZOOKEEPER-1560:
--

It seems like in a particular iteration, 0 bytes is written:

{code}
localhost/127.0.0.1:11222, unexpected error, closing socket connection and 
attempting reconnect
 [exec] [junit] java.io.IOException: Couldn't write 2000 bytes, 0 bytes 
written in this iteration and 77152 bytes written in total. Original limit: 
500074
 [exec] [junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doIO(ClientCnxnSocketNIO.java:145)
 [exec] [junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:375)
 [exec] [junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1068)
 [exec] [junit] 2012-10-12 15:20:42,629 [myid:] - WARN  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11222:NIOServerCnxn@349] - caught end of 
stream exception
 [exec] [junit] EndOfStreamException: Unable to read additional data 
from client sessionid 0x13a55902b650001, likely client has closed socket
 [exec] [junit] at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:220)
 [exec] [junit] at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
 [exec] [junit] at java.lang.Thread.run(Thread.java:662)
 [exec] [junit] 2012-10-12 15:20:42,630 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11222:NIOServerCnxn@1001] - Closed socket 
connection for client /127.0.0.1:57126 which had sessionid 0x13a55902b650001
{code}

Seems like there's a strange resemblance among all the test failures thus far: 
always fails after 77152 bytes written.

 Zookeeper client hangs on creation of large nodes
 -

 Key: ZOOKEEPER-1560
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1560
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.4, 3.5.0
Reporter: Igor Motov
Assignee: Ted Yu
 Fix For: 3.5.0, 3.4.5

 Attachments: ZOOKEEPER-1560.patch, zookeeper-1560-v1.txt, 
 zookeeper-1560-v2.txt, zookeeper-1560-v3.txt, zookeeper-1560-v4.txt, 
 zookeeper-1560-v5.txt, zookeeper-1560-v6.txt


 To reproduce, try creating a node with 0.5M of data using java client. The 
 test will hang waiting for a response from the server. See the attached patch 
 for the test that reproduces the issue.
 It seems that ZOOKEEPER-1437 introduced a few issues to 
 {{ClientCnxnSocketNIO.doIO}} that prevent {{ClientCnxnSocketNIO}} from 
 sending large packets that require several invocations of 
 {{SocketChannel.write}} to complete. The first issue is that the call to 
 {{outgoingQueue.removeFirstOccurrence(p);}} removes the packet from the queue 
 even if the packet wasn't completely sent yet.  It looks to me that this call 
 should be moved under {{if (!pbb.hasRemaining())}} The second issue is that 
 {{p.createBB()}} is reinitializing {{ByteBuffer}} on every iteration, which 
 confuses {{SocketChannel.write}}. And the third issue is caused by extra 
 calls to {{cnxn.getXid()}} that increment xid on every iteration and confuse 
 the server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1557) jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471671#comment-13471671
 ] 

Eugene Koontz commented on ZOOKEEPER-1557:
--

Hi Mahadev, 
It sounds fine to me to release 3.4.5 as is. I'm sure we'll eventually figure 
out what's going on with this. Searching for Junit and JDK7 I found this: 
http://wiki.apidesign.org/wiki/OrderOfElements ; might be relevant.

-Eugene

 jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
 -

 Key: ZOOKEEPER-1557
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1557
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0, 3.4.5
Reporter: Patrick Hunt
Assignee: Eugene Koontz
 Fix For: 3.5.0, 3.4.6

 Attachments: jstack.out, SaslAuthFailTest.log, ZOOKEEPER-1557.patch


 Failure of testBadSaslAuthNotifiesWatch on the jenkins jdk7 job:
 https://builds.apache.org/job/ZooKeeper-trunk-jdk7/407/
 haven't seen this before.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1477) Test failures with Java 7 on Mac OS X

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471377#comment-13471377
 ] 

Eugene Koontz commented on ZOOKEEPER-1477:
--

Thanks Martin, Good to know that multiple Java versions in OS X works.

 Test failures with Java 7 on Mac OS X
 -

 Key: ZOOKEEPER-1477
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1477
 Project: ZooKeeper
  Issue Type: Bug
  Components: server, tests
Affects Versions: 3.4.3
 Environment: Mac OS X Lion (10.7.4)
 Java version:
 java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
Reporter: Diwaker Gupta
 Fix For: 3.4.6

 Attachments: with-ZK-1550.txt


 I downloaded ZK 3.4.3 sources and ran {{ant test}}. Many of the tests failed, 
 including ZooKeeperTest. A common symptom was spurious 
 {{ConnectionLossException}}:
 {code}
 2012-06-01 12:01:23,420 [myid:] - INFO  
 [main:JUnit4ZKTestRunner$LoggedInvokeMethod@54] - TEST METHOD FAILED 
 testDeleteRecursiveAsync
 org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
 = ConnectionLoss for /
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
 at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1246)
 at 
 org.apache.zookeeper.ZooKeeperTest.testDeleteRecursiveAsync(ZooKeeperTest.java:77)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ... (snipped)
 {code}
 As background, I was actually investigating some non-deterministic failures 
 when using Netflix's Curator with Java 7 (see 
 https://github.com/Netflix/curator/issues/79). After a while, I figured I 
 should establish a clean ZK baseline first and realized it is actually a ZK 
 issue, not a Curator issue.
 We are trying to migrate to Java 7 but this is a blocking issue for us right 
 now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1557) jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1557:
-

Attachment: ZOOKEEPER-1557.patch

 jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
 -

 Key: ZOOKEEPER-1557
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1557
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0, 3.4.5
Reporter: Patrick Hunt
Assignee: Eugene Koontz
 Fix For: 3.5.0, 3.4.5

 Attachments: ZOOKEEPER-1557.patch


 Failure of testBadSaslAuthNotifiesWatch on the jenkins jdk7 job:
 https://builds.apache.org/job/ZooKeeper-trunk-jdk7/407/
 haven't seen this before.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1557) jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1557:
-

Attachment: jstack.out

jstack of test's JVM - note the thread waiting in SessionTrackerImpl.java:146, 
which is inside {{while(running)}}, indicating that for this thread, 
{{running==true}}.

 jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
 -

 Key: ZOOKEEPER-1557
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1557
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0, 3.4.5
Reporter: Patrick Hunt
Assignee: Eugene Koontz
 Fix For: 3.5.0, 3.4.5

 Attachments: jstack.out, ZOOKEEPER-1557.patch


 Failure of testBadSaslAuthNotifiesWatch on the jenkins jdk7 job:
 https://builds.apache.org/job/ZooKeeper-trunk-jdk7/407/
 haven't seen this before.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1557) jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1557:
-

Attachment: SaslAuthFailTest.log

tail end of test's log. Note the line:

{code}
[junit] 2012-10-06 13:26:06,001 [myid:] - INFO  
[SessionTracker:SessionTrackerImpl@162] - SessionTrackerImpl exited loop!
{code}

This line is only reachable if {{runnable=false}}, or if there was an 
{{InterruptedException}} caught, which would log an {{Unexpected interruption}} 
error message, which does not appear.

 jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
 -

 Key: ZOOKEEPER-1557
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1557
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0, 3.4.5
Reporter: Patrick Hunt
Assignee: Eugene Koontz
 Fix For: 3.5.0, 3.4.5

 Attachments: jstack.out, SaslAuthFailTest.log, ZOOKEEPER-1557.patch


 Failure of testBadSaslAuthNotifiesWatch on the jenkins jdk7 job:
 https://builds.apache.org/job/ZooKeeper-trunk-jdk7/407/
 haven't seen this before.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1557) jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470068#comment-13470068
 ] 

Eugene Koontz commented on ZOOKEEPER-1557:
--

Taking a look. Although they are different test failures (SaslAuthFailTest vs 
WatcherTest), perhaps they're both related in some way.

 jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
 -

 Key: ZOOKEEPER-1557
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1557
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0, 3.4.5
Reporter: Patrick Hunt
Assignee: Eugene Koontz
 Fix For: 3.5.0, 3.4.5


 Failure of testBadSaslAuthNotifiesWatch on the jenkins jdk7 job:
 https://builds.apache.org/job/ZooKeeper-trunk-jdk7/407/
 haven't seen this before.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1554) Can't use zookeeper client without SASL

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13468661#comment-13468661
 ] 

Eugene Koontz commented on ZOOKEEPER-1554:
--

Hi Guilliame,

 Can you please try the 3.5.0 release candidate 
(http://people.apache.org/~mahadev/zookeeper-3.4.5-candidate-0/). I think this 
might fix your problem. It addresses ZOOKEEPER-1550, which may be the same as 
the issue you are reporting.

Also, in your last comment, you mean 3.4.3, not 4.3.3, right?

-Eugene

 Can't use zookeeper client without SASL
 ---

 Key: ZOOKEEPER-1554
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1554
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.4
Reporter: Guillaume Nodet
Priority: Blocker

 The ZooKeeperSaslClient correctly detects that it should not use SASL when 
 nothing is configured, however the SendThread waits forever because 
 clientTunneledAuthenticationInProgress() returns true instead of false.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1550) ZooKeeperSaslClient does not finish anonymous login on OpenJDK

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1550:
-

Attachment: ZOOKEEPER-1550.patch

-Add accessor: Login.getLoginContextName() for use with test
-Remove loginContextName member from ZooKeeperSaslClient; use 
login.getLoginContextName() instead

Passes ant test on OpenJDK 1.6 and Oracle JDK 1.6 and 1.7. Have not tried 
OpenJDK 1.7 yet.

 ZooKeeperSaslClient does not finish anonymous login on OpenJDK
 --

 Key: ZOOKEEPER-1550
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1550
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.4
Reporter: Robert Macomber
Assignee: Eugene Koontz
Priority: Blocker
 Fix For: 3.4.5

 Attachments: ZOOKEEPER-1550.patch, ZOOKEEPER-1550.patch, 
 ZOOKEEPER-1550.patch


 On OpenJDK, {{javax.security.auth.login.Configuration.getConfiguration}} does 
 not throw an exception.  
 {{ZooKeeperSaslClient.clientTunneledAuthenticationInProgress}} uses an 
 exception from that method as a proxy for this client is not configured to 
 use SASL and as a result no commands can be sent, since it is still waiting 
 for auth to complete.
 [Link to mailing list 
 discussion|http://comments.gmane.org/gmane.comp.java.zookeeper.user/2667]
 The relevant bit of logs from OpenJDK and Oracle versions of 'connect and do 
 getChildren(/)':
 {code:title=OpenJDK}
 INFO [main] 2012-09-25 14:02:24,545 com.socrata.Main Waiting for connection...
 DEBUG [main] 2012-09-25 14:02:24,548 com.socrata.zookeeper.ZooKeeperProvider 
 Waiting for connected-state...
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,576 
 org.apache.zookeeper.ClientCnxn Opening socket connection to server 
 mike.local/10.0.2.106:2181. Will not attempt to authenticate using SASL 
 (unknown error)
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,584 
 org.apache.zookeeper.ClientCnxn Socket connection established to 
 mike.local/10.0.2.106:2181, initiating session
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,586 
 org.apache.zookeeper.ClientCnxn Session establishment request sent on 
 mike.local/10.0.2.106:2181
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,600 
 org.apache.zookeeper.ClientCnxn Session establishment complete on server 
 mike.local/10.0.2.106:2181, sessionid = 0x139ff2e85b60005, negotiated timeout 
 = 4
 DEBUG [main-EventThread] 2012-09-25 14:02:24,614 
 com.socrata.zookeeper.ZooKeeperProvider ConnectionStateChanged(Connected)
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,636 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,923 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null 

[jira] [Commented] (ZOOKEEPER-1477) Test failures with Java 7 on Mac OS X

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464903#comment-13464903
 ] 

Eugene Koontz commented on ZOOKEEPER-1477:
--

Sorry, meant lets 'ant clean test' pass with Oracle Java 7 on Linux

 Test failures with Java 7 on Mac OS X
 -

 Key: ZOOKEEPER-1477
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1477
 Project: ZooKeeper
  Issue Type: Bug
  Components: server, tests
Affects Versions: 3.4.3
 Environment: Mac OS X Lion (10.7.4)
 Java version:
 java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
Reporter: Diwaker Gupta
Priority: Blocker
 Fix For: 3.4.5


 I downloaded ZK 3.4.3 sources and ran {{ant test}}. Many of the tests failed, 
 including ZooKeeperTest. A common symptom was spurious 
 {{ConnectionLossException}}:
 {code}
 2012-06-01 12:01:23,420 [myid:] - INFO  
 [main:JUnit4ZKTestRunner$LoggedInvokeMethod@54] - TEST METHOD FAILED 
 testDeleteRecursiveAsync
 org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
 = ConnectionLoss for /
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
 at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1246)
 at 
 org.apache.zookeeper.ZooKeeperTest.testDeleteRecursiveAsync(ZooKeeperTest.java:77)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ... (snipped)
 {code}
 As background, I was actually investigating some non-deterministic failures 
 when using Netflix's Curator with Java 7 (see 
 https://github.com/Netflix/curator/issues/79). After a while, I figured I 
 should establish a clean ZK baseline first and realized it is actually a ZK 
 issue, not a Curator issue.
 We are trying to migrate to Java 7 but this is a blocking issue for us right 
 now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1477) Test failures with Java 7 on Mac OS X

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464979#comment-13464979
 ] 

Eugene Koontz commented on ZOOKEEPER-1477:
--

I noted this in javac's output when using Oracle Java 7 on Linux:

{code}
compile:
[javac] Compiling 164 source files to /home/ec2-user/zookeeper/build/classes
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.5
[javac] 
/home/ec2-user/zookeeper/src/java/main/org/apache/zookeeper/jmx/ManagedUtil.java:62:
 warning: [rawtypes] found raw type: Enumeration
[javac] Enumeration enumer = r.getCurrentLoggers();
[javac] ^
[javac]   missing type arguments for generic class EnumerationE
[javac]   where E is a type-variable:
[javac] E extends Object declared in interface Enumeration
[javac] 
/home/ec2-user/zookeeper/src/java/main/org/apache/zookeeper/server/util/KerberosUtil.java:39:
 warning: [rawtypes] found raw type: Class
[javac] getInstanceMethod = classRef.getMethod(getInstance, new 
Class[0]);
[javac]   ^
[javac]   missing type arguments for generic class ClassT
[javac]   where T is a type-variable:
[javac] T extends Object declared in class Class
[javac] 
/home/ec2-user/zookeeper/src/java/main/org/apache/zookeeper/server/util/KerberosUtil.java:42:
 warning: [rawtypes] found raw type: Class
[javac]  new Class[0]);
[javac]  ^
[javac]   missing type arguments for generic class ClassT
[javac]   where T is a type-variable:
[javac] T extends Object declared in class Class
[javac] 4 warnings
{code}

 Test failures with Java 7 on Mac OS X
 -

 Key: ZOOKEEPER-1477
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1477
 Project: ZooKeeper
  Issue Type: Bug
  Components: server, tests
Affects Versions: 3.4.3
 Environment: Mac OS X Lion (10.7.4)
 Java version:
 java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
Reporter: Diwaker Gupta
Priority: Blocker
 Fix For: 3.4.5


 I downloaded ZK 3.4.3 sources and ran {{ant test}}. Many of the tests failed, 
 including ZooKeeperTest. A common symptom was spurious 
 {{ConnectionLossException}}:
 {code}
 2012-06-01 12:01:23,420 [myid:] - INFO  
 [main:JUnit4ZKTestRunner$LoggedInvokeMethod@54] - TEST METHOD FAILED 
 testDeleteRecursiveAsync
 org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
 = ConnectionLoss for /
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
 at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1246)
 at 
 org.apache.zookeeper.ZooKeeperTest.testDeleteRecursiveAsync(ZooKeeperTest.java:77)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ... (snipped)
 {code}
 As background, I was actually investigating some non-deterministic failures 
 when using Netflix's Curator with Java 7 (see 
 https://github.com/Netflix/curator/issues/79). After a while, I figured I 
 should establish a clean ZK baseline first and realized it is actually a ZK 
 issue, not a Curator issue.
 We are trying to migrate to Java 7 but this is a blocking issue for us right 
 now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1477) Test failures with Java 7 on Mac OS X

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13464981#comment-13464981
 ] 

Eugene Koontz commented on ZOOKEEPER-1477:
--

(the above warnings do not appear with Oracle Java 6's javac).

 Test failures with Java 7 on Mac OS X
 -

 Key: ZOOKEEPER-1477
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1477
 Project: ZooKeeper
  Issue Type: Bug
  Components: server, tests
Affects Versions: 3.4.3
 Environment: Mac OS X Lion (10.7.4)
 Java version:
 java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
Reporter: Diwaker Gupta
Priority: Blocker
 Fix For: 3.4.5


 I downloaded ZK 3.4.3 sources and ran {{ant test}}. Many of the tests failed, 
 including ZooKeeperTest. A common symptom was spurious 
 {{ConnectionLossException}}:
 {code}
 2012-06-01 12:01:23,420 [myid:] - INFO  
 [main:JUnit4ZKTestRunner$LoggedInvokeMethod@54] - TEST METHOD FAILED 
 testDeleteRecursiveAsync
 org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
 = ConnectionLoss for /
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
 at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1246)
 at 
 org.apache.zookeeper.ZooKeeperTest.testDeleteRecursiveAsync(ZooKeeperTest.java:77)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ... (snipped)
 {code}
 As background, I was actually investigating some non-deterministic failures 
 when using Netflix's Curator with Java 7 (see 
 https://github.com/Netflix/curator/issues/79). After a while, I figured I 
 should establish a clean ZK baseline first and realized it is actually a ZK 
 issue, not a Curator issue.
 We are trying to migrate to Java 7 but this is a blocking issue for us right 
 now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1477) Test failures with Java 7 on Mac OS X

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13465105#comment-13465105
 ] 

Eugene Koontz commented on ZOOKEEPER-1477:
--

Thanks Diwaker, I predict you will get fewer errors, at least, if not zero :) 

May I ask, are you able to install JDK7 on Mac OS X and still be able to select 
JDK and JVM 6? I'd like to try to install JDK 7 but only if I can still select 
JDK/JVM 6 for testing.

 Test failures with Java 7 on Mac OS X
 -

 Key: ZOOKEEPER-1477
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1477
 Project: ZooKeeper
  Issue Type: Bug
  Components: server, tests
Affects Versions: 3.4.3
 Environment: Mac OS X Lion (10.7.4)
 Java version:
 java version 1.7.0_04
 Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)
Reporter: Diwaker Gupta
Priority: Blocker
 Fix For: 3.4.5


 I downloaded ZK 3.4.3 sources and ran {{ant test}}. Many of the tests failed, 
 including ZooKeeperTest. A common symptom was spurious 
 {{ConnectionLossException}}:
 {code}
 2012-06-01 12:01:23,420 [myid:] - INFO  
 [main:JUnit4ZKTestRunner$LoggedInvokeMethod@54] - TEST METHOD FAILED 
 testDeleteRecursiveAsync
 org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode 
 = ConnectionLoss for /
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
 at 
 org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
 at org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1246)
 at 
 org.apache.zookeeper.ZooKeeperTest.testDeleteRecursiveAsync(ZooKeeperTest.java:77)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 ... (snipped)
 {code}
 As background, I was actually investigating some non-deterministic failures 
 when using Netflix's Curator with Java 7 (see 
 https://github.com/Netflix/curator/issues/79). After a while, I figured I 
 should establish a clean ZK baseline first and realized it is actually a ZK 
 issue, not a Curator issue.
 We are trying to migrate to Java 7 but this is a blocking issue for us right 
 now.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1550) ZooKeeperSaslClient does not finish anonymous login on OpenJDK

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13463992#comment-13463992
 ] 

Eugene Koontz commented on ZOOKEEPER-1550:
--

Robert mentions in mailing list thread linked above that this bug happens on 
both Openjdk 6 and Openjdk 7 on Ubuntu and Debian Linux.

 ZooKeeperSaslClient does not finish anonymous login on OpenJDK
 --

 Key: ZOOKEEPER-1550
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1550
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.4
Reporter: Robert Macomber
Priority: Blocker
 Fix For: 3.4.5


 On OpenJDK, {{javax.security.auth.login.Configuration.getConfiguration}} does 
 not throw an exception.  
 {{ZooKeeperSaslClient.clientTunneledAuthenticationInProgress}} uses an 
 exception from that method as a proxy for this client is not configured to 
 use SASL and as a result no commands can be sent, since it is still waiting 
 for auth to complete.
 [Link to mailing list 
 discussion|http://comments.gmane.org/gmane.comp.java.zookeeper.user/2667]
 The relevant bit of logs from OpenJDK and Oracle versions of 'connect and do 
 getChildren(/)':
 {code:title=OpenJDK}
 INFO [main] 2012-09-25 14:02:24,545 com.socrata.Main Waiting for connection...
 DEBUG [main] 2012-09-25 14:02:24,548 com.socrata.zookeeper.ZooKeeperProvider 
 Waiting for connected-state...
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,576 
 org.apache.zookeeper.ClientCnxn Opening socket connection to server 
 mike.local/10.0.2.106:2181. Will not attempt to authenticate using SASL 
 (unknown error)
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,584 
 org.apache.zookeeper.ClientCnxn Socket connection established to 
 mike.local/10.0.2.106:2181, initiating session
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,586 
 org.apache.zookeeper.ClientCnxn Session establishment request sent on 
 mike.local/10.0.2.106:2181
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,600 
 org.apache.zookeeper.ClientCnxn Session establishment complete on server 
 mike.local/10.0.2.106:2181, sessionid = 0x139ff2e85b60005, negotiated timeout 
 = 4
 DEBUG [main-EventThread] 2012-09-25 14:02:24,614 
 com.socrata.zookeeper.ZooKeeperProvider ConnectionStateChanged(Connected)
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,636 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,923 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO 

[jira] [Updated] (ZOOKEEPER-1550) ZooKeeperSaslClient does not finish anonymous login on OpenJDK

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1550:
-

Attachment: ZOOKEEPER-1550.patch

-checks for non-null designated client login AppConfigurationEntry. (rather 
than just a non-null login Configuration).
-adds client-side test related to login configuration
-adds ZooKeeper:getSaslClient() method so that the above test can work.

 ZooKeeperSaslClient does not finish anonymous login on OpenJDK
 --

 Key: ZOOKEEPER-1550
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1550
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.4
Reporter: Robert Macomber
Assignee: Eugene Koontz
Priority: Blocker
 Fix For: 3.4.5

 Attachments: ZOOKEEPER-1550.patch


 On OpenJDK, {{javax.security.auth.login.Configuration.getConfiguration}} does 
 not throw an exception.  
 {{ZooKeeperSaslClient.clientTunneledAuthenticationInProgress}} uses an 
 exception from that method as a proxy for this client is not configured to 
 use SASL and as a result no commands can be sent, since it is still waiting 
 for auth to complete.
 [Link to mailing list 
 discussion|http://comments.gmane.org/gmane.comp.java.zookeeper.user/2667]
 The relevant bit of logs from OpenJDK and Oracle versions of 'connect and do 
 getChildren(/)':
 {code:title=OpenJDK}
 INFO [main] 2012-09-25 14:02:24,545 com.socrata.Main Waiting for connection...
 DEBUG [main] 2012-09-25 14:02:24,548 com.socrata.zookeeper.ZooKeeperProvider 
 Waiting for connected-state...
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,576 
 org.apache.zookeeper.ClientCnxn Opening socket connection to server 
 mike.local/10.0.2.106:2181. Will not attempt to authenticate using SASL 
 (unknown error)
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,584 
 org.apache.zookeeper.ClientCnxn Socket connection established to 
 mike.local/10.0.2.106:2181, initiating session
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,586 
 org.apache.zookeeper.ClientCnxn Session establishment request sent on 
 mike.local/10.0.2.106:2181
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,600 
 org.apache.zookeeper.ClientCnxn Session establishment complete on server 
 mike.local/10.0.2.106:2181, sessionid = 0x139ff2e85b60005, negotiated timeout 
 = 4
 DEBUG [main-EventThread] 2012-09-25 14:02:24,614 
 com.socrata.zookeeper.ZooKeeperProvider ConnectionStateChanged(Connected)
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,636 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,923 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null 

[jira] [Updated] (ZOOKEEPER-1550) ZooKeeperSaslClient does not finish anonymous login on OpenJDK

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1550:
-

Attachment: ZOOKEEPER-1550.patch

Fix typo and incorrect use of 'assertEquals' in last patch - sorry for that!

 ZooKeeperSaslClient does not finish anonymous login on OpenJDK
 --

 Key: ZOOKEEPER-1550
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1550
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.4
Reporter: Robert Macomber
Assignee: Eugene Koontz
Priority: Blocker
 Fix For: 3.4.5

 Attachments: ZOOKEEPER-1550.patch, ZOOKEEPER-1550.patch


 On OpenJDK, {{javax.security.auth.login.Configuration.getConfiguration}} does 
 not throw an exception.  
 {{ZooKeeperSaslClient.clientTunneledAuthenticationInProgress}} uses an 
 exception from that method as a proxy for this client is not configured to 
 use SASL and as a result no commands can be sent, since it is still waiting 
 for auth to complete.
 [Link to mailing list 
 discussion|http://comments.gmane.org/gmane.comp.java.zookeeper.user/2667]
 The relevant bit of logs from OpenJDK and Oracle versions of 'connect and do 
 getChildren(/)':
 {code:title=OpenJDK}
 INFO [main] 2012-09-25 14:02:24,545 com.socrata.Main Waiting for connection...
 DEBUG [main] 2012-09-25 14:02:24,548 com.socrata.zookeeper.ZooKeeperProvider 
 Waiting for connected-state...
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,576 
 org.apache.zookeeper.ClientCnxn Opening socket connection to server 
 mike.local/10.0.2.106:2181. Will not attempt to authenticate using SASL 
 (unknown error)
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,584 
 org.apache.zookeeper.ClientCnxn Socket connection established to 
 mike.local/10.0.2.106:2181, initiating session
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,586 
 org.apache.zookeeper.ClientCnxn Session establishment request sent on 
 mike.local/10.0.2.106:2181
 INFO [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,600 
 org.apache.zookeeper.ClientCnxn Session establishment complete on server 
 mike.local/10.0.2.106:2181, sessionid = 0x139ff2e85b60005, negotiated timeout 
 = 4
 DEBUG [main-EventThread] 2012-09-25 14:02:24,614 
 com.socrata.zookeeper.ZooKeeperProvider ConnectionStateChanged(Connected)
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:24,636 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,923 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:37,924 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,260 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:/ serverPath:/ finished:false header:: 0,12  replyHeader:: 0,0,0 
 request:: '/,F  response:: v{} until SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 org.apache.zookeeper.ClientCnxnSocketNIO deferring non-priming packet: 
 clientPath:null serverPath:null finished:false header:: -2,11  replyHeader:: 
 null request:: null response:: nulluntil SASL authentication completes.
 DEBUG [main-SendThread(mike.local:2181)] 2012-09-25 14:02:51,261 
 

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Fixes SaslAuthDesignatedServerTest by checking for both system property 
JAAS_CONF_KEY and java.security.auth.login.Configuration.getConfiguration().

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (ZOOKEEPER-1547) Improve robustness of client using Sasl in the presence of dropped requests

[Eugene Koontz (JIRA)]

Eugene Koontz created ZOOKEEPER-1547:


 Summary: Improve robustness of client using Sasl in the presence 
of dropped requests
 Key: ZOOKEEPER-1547
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1547
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Eugene Koontz


ZK clients send SASL packets to ZK servers as request packets. However, what if 
the server does not responds to the client's SASL packets with responses? The 
server does not actually close the connection to the client, it simply fails to 
respond to SASL requests. Make sure the client can cope with this behavior.

Background:

In ZOOKEEPER-1437, Ben writes: 

[I]t would be great to add a test that simply drops responses to clients 
without closing connections.

https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13447477page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447477

Also in ZOOKEEPER-1437 Rakesh writes: I could see 
DisconnectableZooKeeper.disconnect() has network delays/partition simulation 
logic.

https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13445704page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13445704



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448031#comment-13448031
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Rakesh and Ben,

I've added https://issues.apache.org/jira/browse/ZOOKEEPER-1437 based on your 
comments. I addressed it specifically to SASL, though perhaps it is a more 
general issue of testing the client's coping with all kinds of dropped packets, 
not just SASL ones.


 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448032#comment-13448032
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Sorry, meant to link to ZOOKEEPER-1547.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Merge with trunk and pass along exception as second argument of SaslException. 
Thanks to Rakesh for pointing it out.


 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1547) Test robustness of client using SASL in the presence of dropped requests

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1547:
-

Summary: Test robustness of client using SASL in the presence of dropped 
requests  (was: Test robustness of client using Sasl in the presence of dropped 
requests)

 Test robustness of client using SASL in the presence of dropped requests
 

 Key: ZOOKEEPER-1547
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1547
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Eugene Koontz

 ZK clients send SASL packets to ZK servers as request packets. However, what 
 if the server does not responds to the client's SASL packets with responses? 
 The server does not actually close the connection to the client, it simply 
 fails to respond to SASL requests. Make sure the client can cope with this 
 behavior.
 Background:
 In ZOOKEEPER-1437, Ben writes: 
 [I]t would be great to add a test that simply drops responses to clients 
 without closing connections.
 https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13447477page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13447477
 Also in ZOOKEEPER-1437 Rakesh writes: I could see 
 DisconnectableZooKeeper.disconnect() has network delays/partition simulation 
 logic.
 https://issues.apache.org/jira/browse/ZOOKEEPER-1437?focusedCommentId=13445704page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13445704

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448047#comment-13448047
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Ben, You are right: a new ZooKeeperSaslClient will be created for each new 
connection, since it's a member variable of a ClientCnxn. So it doesn't seem 
possible for a ZooKeeperSaslClient to retry across two subsequent connections.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445300#comment-13445300
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Rakesh,
 
Sorry to take a long time to respond to you. I'll try to be more prompt 
especially as folks are hoping to get this in a release soon.


 I see what you are asking: should we retry if there's a network error 
connecting to the client (in your terms, a partition)?

 I guess we could add some retry logic - something like:

{code}
while (!(saslClient.isComplete()) {
   try {
 sendSaslPacket(saslToken, cnxn); // throws SaslException, IOException
   } catch (IOException ne) {
 // transitory network failure: keep trying to reach server
   } catch (SaslException se) {
 // auth failed: nothing more we can do.
 break;
   }
}
{code}

Is that what you had in mind? 

I think it would be good to test the SASL exchange in the presence of network 
failures - I'm wondering what support there is already in Zookeeper tests for 
network failure and if so, can we use them to test the SASL exchange.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: getXidCallHierarchy.png, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1525) Plumb ZooKeeperServer object into auth plugins

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13429930#comment-13429930
 ] 

Eugene Koontz commented on ZOOKEEPER-1525:
--

Hi Warren,

I'm not sure why the Jenkins build did not get triggered here on your patch.

Although, even if Jenkins was triggered, I'm afraid this patch might not work 
with Jenkins because it has a/ and b/ paths in the patch. I think you need 
to add 

{code}
[diff]
 noprefix = true
{code}

to your ~/.gitconfig.

 Plumb ZooKeeperServer object into auth plugins
 --

 Key: ZOOKEEPER-1525
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1525
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Warren Turkal
 Attachments: ZOOKEEPER-1525.patch, ZOOKEEPER-1525.patch


 I want to plumb the ZooKeeperServer object into the auth plugins so that I 
 can store authentication data in zookeeper itself. With access to the 
 ZooKeeperServer object, I also have access to the ZKDatabase and can look up 
 entries in the local copy of the zookeeper data.
 In order to implement this, I make sure that a ZooKeeperServer instance is 
 passed in to the ProviderRegistry.initialize() method. Then initialize() will 
 try to find a constructor for the AuthenticationProvider that takes a 
 ZooKeeperServer instance. If the constructor is found, it will be used. 
 Otherwise, initialize() will look for a constructor that takes no arguments 
 and use that instead.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (ZOOKEEPER-1524) use more standard junit constructs before/after or beforeclass/afterclass in SaslAuthTest and SaslAuthFailTest rather than static blocks

[Eugene Koontz (JIRA)]

Eugene Koontz created ZOOKEEPER-1524:


 Summary: use more standard junit constructs before/after or 
beforeclass/afterclass in SaslAuthTest and SaslAuthFailTest rather than 
static blocks
 Key: ZOOKEEPER-1524
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1524
 Project: ZooKeeper
  Issue Type: Improvement
  Components: tests
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Minor


The following tests:

AuthTest.java
SaslAuthFailTest.java
SaslAuthDesignatedClientTest.java
SaslAuthFailDesignatedClientTest.java
SaslAuthMissingClientConfigTest.java
SaslAuthTest.java

use static {..} blocks to initialize system properties and files prior to the 
test runs. As Patrick points out in ZOOKEEPER-1503, we should instead use 
JUnit's @Before annotation:


http://junit.sourceforge.net/javadoc/org/junit/Before.html

rather than static blocks, to make our tests more consistent and easier to 
understand.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1524) use more standard junit annotation @Before in SaslAuthTest and SaslAuthFailTest rather than static blocks

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1524:
-

Summary: use more standard junit annotation @Before in SaslAuthTest and 
SaslAuthFailTest rather than static blocks  (was: use more standard junit 
constructs before/after or beforeclass/afterclass in SaslAuthTest and 
SaslAuthFailTest rather than static blocks)

 use more standard junit annotation @Before in SaslAuthTest and 
 SaslAuthFailTest rather than static blocks
 ---

 Key: ZOOKEEPER-1524
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1524
 Project: ZooKeeper
  Issue Type: Improvement
  Components: tests
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Minor

 The following tests:
 AuthTest.java
 SaslAuthFailTest.java
 SaslAuthDesignatedClientTest.java
 SaslAuthFailDesignatedClientTest.java
 SaslAuthMissingClientConfigTest.java
 SaslAuthTest.java
 use static {..} blocks to initialize system properties and files prior to 
 the test runs. As Patrick points out in ZOOKEEPER-1503, we should instead use 
 JUnit's @Before annotation:
 http://junit.sourceforge.net/javadoc/org/junit/Before.html
 rather than static blocks, to make our tests more consistent and easier to 
 understand.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1524) use more standard junit annotation @Before in SaslXTests rather than static blocks

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1524:
-

Summary: use more standard junit annotation @Before in SaslXTests rather 
than static blocks  (was: use more standard junit annotation @Before in 
SaslAuthTest and SaslAuthFailTest rather than static blocks)

 use more standard junit annotation @Before in SaslXTests rather than static 
 blocks
 

 Key: ZOOKEEPER-1524
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1524
 Project: ZooKeeper
  Issue Type: Improvement
  Components: tests
Reporter: Eugene Koontz
Assignee: Eugene Koontz
Priority: Minor

 The following tests:
 AuthTest.java
 SaslAuthFailTest.java
 SaslAuthDesignatedClientTest.java
 SaslAuthFailDesignatedClientTest.java
 SaslAuthMissingClientConfigTest.java
 SaslAuthTest.java
 use static {..} blocks to initialize system properties and files prior to 
 the test runs. As Patrick points out in ZOOKEEPER-1503, we should instead use 
 JUnit's @Before annotation:
 http://junit.sourceforge.net/javadoc/org/junit/Before.html
 rather than static blocks, to make our tests more consistent and easier to 
 understand.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1503) remove redundant JAAS configuration code in SaslAuthTest and SaslAuthFailTest

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13426858#comment-13426858
 ] 

Eugene Koontz commented on ZOOKEEPER-1503:
--

Sure thing, thanks for noticing that, Patrick.

https://issues.apache.org/jira/browse/ZOOKEEPER-1524


 remove redundant JAAS configuration code in SaslAuthTest and SaslAuthFailTest
 -

 Key: ZOOKEEPER-1503
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1503
 Project: ZooKeeper
  Issue Type: Improvement
 Environment: In SaslAuthTest and SaslAuthFail test, we set the JAAS 
 configuration twice with the same text string. This is confusing and 
 redundant, since we need only set it once.
Reporter: Eugene Koontz
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1503.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1510) Should not log SASL errors for non-secure usage

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13415724#comment-13415724
 ] 

Eugene Koontz commented on ZOOKEEPER-1510:
--

Looks like a good change to me. It's always interesting to hear users' 
reactions to what they're seeing.

 Should not log SASL errors for non-secure usage
 ---

 Key: ZOOKEEPER-1510
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1510
 Project: ZooKeeper
  Issue Type: Improvement
  Components: java client
Affects Versions: 3.4.3
Reporter: Todd Lipcon
Assignee: Todd Lipcon
Priority: Minor
 Attachments: zookeeper-1510.txt


 Since SASL support was added, all connections with non-secure clients have 
 started logging messages like:
 2012-07-01 02:13:34,986 WARN org.apache.zookeeper.client.ZooKeeperSaslClient: 
 SecurityException: java.lang.SecurityException: Unable to locate a login 
 configuration occurred when trying to find JAAS configuration.
 2012-07-01 02:13:34,986 INFO org.apache.zookeeper.client.ZooKeeperSaslClient: 
 Client will not SASL-authenticate because the default JAAS configuration 
 section 'Client' could not be found. If you are not using SASL, you may 
 ignore this. On the other hand, if you expected SASL to work, please fix your 
 JAAS configuration.
 Despite the you may ignore this qualifier, I've seen a lot of users 
 confused by this message. Instead, it would be better to either log at DEBUG 
 level, or piggy back the SASL information onto the Opening socket 
 connection message (eg Opening socket connection to X:2181. Will not use 
 SASL because no configuration was located.)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1497) Allow server-side SASL login with JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1497:
-

Summary: Allow server-side SASL login with JAAS configuration to be 
programmatically set (rather than only by reading JAAS configuration file)  
(was: Allow SASL login with JAAS configuration to be programmatically set 
(rather than only by reading JAAS configuration file))

 Allow server-side SASL login with JAAS configuration to be programmatically 
 set (rather than only by reading JAAS configuration file)
 -

 Key: ZOOKEEPER-1497
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1497
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.3, 3.3.5
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
  Labels: security
 Attachments: ZOOKEEPER-1497-v1.patch


 Currently the CnxnFactory checks for java.security.auth.login.config to 
 decide whether or not enable SASL.
 * zookeeper/server/NIOServerCnxnFactory.java
 * zookeeper/server/NettyServerCnxnFactory.java
 ** configure() checks for java.security.auth.login.config
 *** If present start the new Login(Server, SaslServerCallbackHandler(conf))
 But since the SaslServerCallbackHandler does the right thing just checking if 
 getAppConfigurationEntry() is empty, we can allow SASL with JAAS 
 configuration to be programmatically just checking weather or not a 
 configuration entry is present instead of java.security.auth.login.config.
 (Something quite similar was done for the SaslClient in ZOOKEEPER-1373)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (ZOOKEEPER-1503) remove redundant SASL configuration code in SaslAuthTest and SaslAuthFailTest

[Eugene Koontz (JIRA)]

Eugene Koontz created ZOOKEEPER-1503:


 Summary: remove redundant SASL configuration code in SaslAuthTest 
and SaslAuthFailTest
 Key: ZOOKEEPER-1503
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1503
 Project: ZooKeeper
  Issue Type: Improvement
 Environment: In SaslAuthTest and SaslAuthFail test, we set the JAAS 
configuration twice with the same text string. This is confusing and redundant, 
since we need only set it once.
Reporter: Eugene Koontz
Assignee: Eugene Koontz




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1503) remove redundant SASL configuration code in SaslAuthTest and SaslAuthFailTest

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1503:
-

Attachment: ZOOKEEPER-1503.patch

 remove redundant SASL configuration code in SaslAuthTest and SaslAuthFailTest
 -

 Key: ZOOKEEPER-1503
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1503
 Project: ZooKeeper
  Issue Type: Improvement
 Environment: In SaslAuthTest and SaslAuthFail test, we set the JAAS 
 configuration twice with the same text string. This is confusing and 
 redundant, since we need only set it once.
Reporter: Eugene Koontz
Assignee: Eugene Koontz
 Attachments: ZOOKEEPER-1503.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1497) Allow server-side SASL login with JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407377#comment-13407377
 ] 

Eugene Koontz commented on ZOOKEEPER-1497:
--

Hi Matteo, 
It looks like a good design overall. 

It's good that we now have (with this patch) zookeeper.sasl.serverconfig as 
well as the existing zookeeper.sasl.clientconfig (from ZOOKEEPER-1373).

I think ServerCnxnFactory.configureSaslLogin() could use some documentation 
about why we throw a caught exception or ignore it.

Some logging at ERROR or WARN level where appropriate, to help ZK admins 
diagnose configuration problems (for example, what if 
zookeeper.sasl.serverconfig references a non-existent JAAS configuration 
section? or, what if java.security.auth.login.config points to a non-existent 
file, but Configuration has been set programmatically and is valid, should we 
ignore the non-existent file and login with the valid Configuration?)

Some additional tests would be good as the QA bot mentioned. See 
SaslAuthDesignatedClientTest.java from ZOOKEEPER-1373 for how I added more 
configuration testing on the Client side. 

Would be nice to test programmatically-set JAAS configuration. Rather than 
writing a string to a temporary file and then setting 
java.security.auth.login.config to point to it, instead, we'd build a 
javax.security.auth.login.Configuration in code in the tests and then call 
Configuration.setConfiguration() (if I understand the API correctly).



 Allow server-side SASL login with JAAS configuration to be programmatically 
 set (rather than only by reading JAAS configuration file)
 -

 Key: ZOOKEEPER-1497
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1497
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.3, 3.3.5
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
  Labels: security
 Attachments: ZOOKEEPER-1497-v1.patch


 Currently the CnxnFactory checks for java.security.auth.login.config to 
 decide whether or not enable SASL.
 * zookeeper/server/NIOServerCnxnFactory.java
 * zookeeper/server/NettyServerCnxnFactory.java
 ** configure() checks for java.security.auth.login.config
 *** If present start the new Login(Server, SaslServerCallbackHandler(conf))
 But since the SaslServerCallbackHandler does the right thing just checking if 
 getAppConfigurationEntry() is empty, we can allow SASL with JAAS 
 configuration to be programmatically just checking weather or not a 
 configuration entry is present instead of java.security.auth.login.config.
 (Something quite similar was done for the SaslClient in ZOOKEEPER-1373)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1497) Allow server-side SASL login with JAAS configuration to be programmatically set (rather than only by reading JAAS configuration file)

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13407382#comment-13407382
 ] 

Eugene Koontz commented on ZOOKEEPER-1497:
--

I added ZOOKEEPER-1503 which would help a bit for adding tests to 
ZOOKEEPER-1497.

 Allow server-side SASL login with JAAS configuration to be programmatically 
 set (rather than only by reading JAAS configuration file)
 -

 Key: ZOOKEEPER-1497
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1497
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.3, 3.3.5
Reporter: Matteo Bertozzi
Assignee: Matteo Bertozzi
  Labels: security
 Attachments: ZOOKEEPER-1497-v1.patch


 Currently the CnxnFactory checks for java.security.auth.login.config to 
 decide whether or not enable SASL.
 * zookeeper/server/NIOServerCnxnFactory.java
 * zookeeper/server/NettyServerCnxnFactory.java
 ** configure() checks for java.security.auth.login.config
 *** If present start the new Login(Server, SaslServerCallbackHandler(conf))
 But since the SaslServerCallbackHandler does the right thing just checking if 
 getAppConfigurationEntry() is empty, we can allow SASL with JAAS 
 configuration to be programmatically just checking weather or not a 
 configuration entry is present instead of java.security.auth.login.config.
 (Something quite similar was done for the SaslClient in ZOOKEEPER-1373)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1503) remove redundant JAAS configuration code in SaslAuthTest and SaslAuthFailTest

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1503:
-

Summary: remove redundant JAAS configuration code in SaslAuthTest and 
SaslAuthFailTest  (was: remove redundant SASL configuration code in 
SaslAuthTest and SaslAuthFailTest)

 remove redundant JAAS configuration code in SaslAuthTest and SaslAuthFailTest
 -

 Key: ZOOKEEPER-1503
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1503
 Project: ZooKeeper
  Issue Type: Improvement
 Environment: In SaslAuthTest and SaslAuthFail test, we set the JAAS 
 configuration twice with the same text string. This is confusing and 
 redundant, since we need only set it once.
Reporter: Eugene Koontz
Assignee: Eugene Koontz
 Attachments: ZOOKEEPER-1503.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406135#comment-13406135
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Mahadev,
Thanks for looking at the patch and your comments. Responding to your comments:

bq.  You added
bq.public boolean readOnly;
bq. In ClientCnxn.java Packet class which doesnt seem to be used anywhere, am I 
correct?

This was added so that packet-serialization can be deferred until the
packet is actually sent: we need to save the readOnly parameter,
passed as an argument to the packet constructor, until it is actually
used in the serialization of the packet. In this patch this
serialization is now done in a newly-added method,
ClientCnxnSocketNIO::sendPacket(), which serializes the input packet
'p' by calling p.createBB(). createBB() uses the packet's 'readOnly'
member variable in order to create the serialization of the packet.

bq.I think we are a little weak on our synchronizations in the
bq.patch. I will take a look again but looks like its using a lot of
bq.member variables which could get changed by various threads.

bq.I think there is a race condition in
bq.ClientCnxnSocketNIO:findSendablePacket() wherein how do you make
bq.sure that the sasl packets (without header) are present in the
bq.queue before we start running the thread. 

I don't think there is a race condition possible. My reasoning is that
the sendThread both sends packets from the outgoingQueue and manages
the {{zooKeeperSaslClient}} object. Therefore it is not possible to send
packets from the outgoing queue (besides the initial priming packet) without 
the {{zooKeeperSaslClient}} being
finished with authentication (whether successfully or not).

In the code from the patch that you
cite, {{clientTunneledAuthenticationInProgress()}} must have returned
false in order to get inside the {{ else{} }}. For
{{clientTunneledAuthenticationInProgress()}} is false, then at least one
of the following must be true:

1. saslAuthFailed is true, or
2. zooKeeperSaslClient's clientTunneledAuthenticationInProgress() is false.

With regard to 1., saslAuthFailed can only be true if a {{LoginException}} was 
caught within
{{startConnect()}}, but {{startConnect()}} can only be run by the sendThread.

With regard to 2., this can only be false if {{gotLastPacket}} is true,
and either:

2.1. saslState is COMPLETE, or 
2.2. saslState is FAILED.

But {{gotLastPacket}} is initialized to false when the sendThread creates it,
and can only be set to true by code run by the sendThread
(specifically by {{ZooKeeperSaslClient::respondToServer()}}).




 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, getXidCallHierarchy.png


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Hi Patrick,

Thanks as always for your comments and help.

With regard to Xids: I don't see how the event thread can call sendPacket(). It 
seems to me that *only* the send thread can call getXid() or sendPacket(), and 
therefore, packets can only be sent in the correct order. 

I put some test logging in ClientCnxn::getXid():

{code}
LOG.info(getXid() being called from thread:  + 
Thread.currentThread().getName());
{code}

and the logging always reports SendThread.

With regard to spinning on the write interest - you are right, this was 
happening. I've created a new patch that prevents spinning in doIO(). It works 
by calling disableWrite() in doIO() if no packet can be sent because SASL 
authentication is ongoing. enableWrite(), in turn, is called after SASL 
authentication is completed. This makes the patch a bit more complicated to 
follow, I'm afraid, but I think I'm on the right track. 

I'm attaching the patch and opening a review on reviews.apache.org as you asked.


 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Fix bug in last patch that was not sending SaslAuthenticated event after 
authentication finishes.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399027#comment-13399027
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Patrick,

Thanks for the information about Eclipse. I'm attaching a screenshot showing my 
Call Hierarchy view.

The code that calls ServerSaslResponseCallback.processResult has been removed 
in the latest patch (as well as in the last few most recent patches). 

(See the section of the patch beginning with @@ -553,17 +551,6 @@ public class 
ClientCnxn { )

So I don't think there's a possibility anymore of the EventThread creating or 
sending packets.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: getXidCallHierarchy.png

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, getXidCallHierarchy.png


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13399033#comment-13399033
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Thanks, Patrick. Also I've created a new review here:

https://reviews.apache.org/r/5505/

-Eugene

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, getXidCallHierarchy.png


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Latest patch fixes problem when using Kerberos as SASL mechanism, because ZK 
server sends a final empty SASL packet at end of authentication. Also tries to 
minimize changes to existing, non-SASL related files.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397916#comment-13397916
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Thanks, Patrick, good to know. I'll use that in the future.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1236) Security uses proprietary Sun APIs

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293682#comment-13293682
 ] 

Eugene Koontz commented on ZOOKEEPER-1236:
--

Hi Adalberto,
 
Please add 
{code}
[diff]
noprefix = true
{code}

to your $HOME/.gitconfig and re-create your patch so that the Hadoop QA process 
can use it.

(I encountered the same problem back when I first started submitting JIRA 
patches)

 Security uses proprietary Sun APIs
 --

 Key: ZOOKEEPER-1236
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1236
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.4.0, 3.4.3
Reporter: Patrick Hunt
Assignee: Eugene Koontz
 Fix For: 3.5.0

 Attachments: zookeeper-1236.patch


 See HADOOP-7211 - Recent kerberos integration resulted in the same issue in 
 ZK.
 {noformat}
 [javac] 
 /home/phunt/dev/zookeeper/src/java/main/org/apache/zookeeper/server/auth/KerberosName.java:88:
  warning: sun.security.krb5.KrbException is Sun proprietary API and may be 
 removed in a future release
 [javac] } catch (KrbException ke) {
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293704#comment-13293704
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Unfortunately I don't know when I can post a review to the reviewboard since it 
seems down for an indefinite period; see 
https://issues.apache.org/jira/browse/INFRA-4888 

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13293850#comment-13293850
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Thanks Andy, using review.cloudera.org: https://review.cloudera.org/r/2150/

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13292593#comment-13292593
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Patrick,
Thanks for your patience and help with this. I am attaching a new patch and 
also creating a review board review for this patch.

In this most recent patch, I am generating the SASL packets on the fly as you 
mentioned, and sending these immediately rather than queuing them. 

Also, there is no synchronization mechanisms (no CountDownLatch) added in this 
patch. This eliminates the blocking in queueing that you pointed out in your 
last comment.

I've moved the Xid-setting of the packets to immediately before they are sent 
(whether they are SASL packets or queued packets), in order to make sure that 
the packets' Xids are always in order of their being sent. 

Thank you Himanshu for your testing - I believe my latest patch will prevent 
packets with out-of-order Xids that you experienced.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Fix findbugs warning introduced in last patch.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13286120#comment-13286120
 ] 

Eugene Koontz commented on ZOOKEEPER-1469:
--

No problem to document this (this would be in the cwiki, I assume, like 
https://cwiki.apache.org/ZOOKEEPER/zookeeper-and-sasl.html). 

Thanks Himanshu for the writeup of your working configuration!

 Adding Cross-Realm support for secure Zookeeper
 ---

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper client authentication

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1469:
-

Summary: Adding Cross-Realm support for secure Zookeeper client 
authentication  (was: Adding Cross-Realm support for secure Zookeeper)

 Adding Cross-Realm support for secure Zookeeper client authentication
 -

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280581#comment-13280581
 ] 

Eugene Koontz commented on ZOOKEEPER-1469:
--

Hi Himanshu, I'm adding a patch to this JIRA to print out the exception that 
was thrown in your log statement above; could you try applying this patch and 
let me know what addition information is shown in your testing scenario?

Thanks, Eugene

 Adding Cross-Realm support for secure Zookeeper
 ---

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: c client, server
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1469:
-

Attachment: SaslServerCallBackHandlerException.patch

print exception thrown from kerberosName.getShortName().

 Adding Cross-Realm support for secure Zookeeper
 ---

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: c client, server
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280637#comment-13280637
 ] 

Eugene Koontz commented on ZOOKEEPER-1469:
--

Thanks Himanshu - can you try setting zookeeper.security.auth_to_local to 
[2:$1] - see : 
https://ccp.cloudera.com/display/CDHDOC/Appendix+C+-+Configuring+the+Mapping+from+Kerberos+Principals+to+Short+Names

-Eugene

 Adding Cross-Realm support for secure Zookeeper
 ---

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: c client, server
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280666#comment-13280666
 ] 

Eugene Koontz commented on ZOOKEEPER-1469:
--

Hey, great to hear that! Patrick deserves the credit for suggesting setting 
auth_to_local. :) 

What shall we do with this JIRA now?

 Adding Cross-Realm support for secure Zookeeper
 ---

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: c client, server
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1469) Adding Cross-Realm support for secure Zookeeper

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13280672#comment-13280672
 ] 

Eugene Koontz commented on ZOOKEEPER-1469:
--

With regard to -requires_preauth, I need to study it further and try to 
reproduce your secure HBase replication setup. We should document within the 
HBase docs what you've accomplished - perhaps an HBase JIRA is warranted 
similar to https://issues.apache.org/jira/browse/HBASE-4960.

 Adding Cross-Realm support for secure Zookeeper
 ---

 Key: ZOOKEEPER-1469
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1469
 Project: ZooKeeper
  Issue Type: Improvement
  Components: c client, server
Affects Versions: 3.4.3
Reporter: Himanshu Vashishtha
 Attachments: SaslServerCallBackHandlerException.patch


 There is a use case where one needs to support cross realm authentication for 
 zookeeper cluster. One use case is HBase Replication: HBase supports 
 replicating data to multiple slave clusters, where the later might be running 
 in different realms. With current zookeeper security, the region server of 
 master HBase cluster are not able to query the zookeeper quorum members of 
 the slave cluster. This jira is about adding such Xrealm support.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279631#comment-13279631
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Antonio, 
(my previous post seems to have failed with a 5xx error, apologies if this is a 
duplicate)

I encourage you to provide a unit test, either with Curator or directly with 
just a Zookeeper client/server setup with a shell script. I git-cloned Curator 
but unfortunately I get some tests failures on trunk with {{./gradelw build}}. 
Nothing against Curator: I would like to learn more about it, but I think it 
would be best to show the problem with purely Zookeeper code as much as 
possible.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279070#comment-13279070
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Antonio, interesting results - you are finding that sending an empty SASL 
response to the Zookeeper server causes an authentication failure? Can you show 
your JAAS configuration for client and server? I see that your paths have 
backslashes in them - you are running the client on Microsoft Windows I assume? 
(not that this should be necessarily be a problem).

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13279272#comment-13279272
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Antonio, 

I think the empty data[] is an artifact of my development process: in my 
testing, I found that if I use Kerberos as the SASL metchanism, the client's 
ZooKeeperSaslClient::ServerSaslResponseCallback::processResult() will be 
supplied with a null data[] array when this method (processResult()) is called 
for the final time. So I had to handle this situation somehow.

One could handle the null server response in a different way, as long as you 
avoid accessing a null pointer, of course - you could check for the null 
pointer in other places, as your patch does. 

However I don't think this is related to the problem you are seeing; or at 
least, I'm not able to reproduce your problem myself. I wonder if you could 
supply a shell script that could reproduce it? Perhaps a script that kills and 
starts the server repeatedly to cause the client to eventually fail to 
authenticate?

-Eugene

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Restore the interrupt state when catching InterruptedException while waiting 
for authentication latch (thanks to Zhihong Yu).

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz reassigned ZOOKEEPER-1467:


Assignee: Eugene Koontz

 Server principal on client side is derived using hostname.
 --

 Key: ZOOKEEPER-1467
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
Reporter: Laxman
Assignee: Eugene Koontz
Priority: Blocker
  Labels: Security, client, kerberos, sasl

 Server principal on client side is derived using hostname.
 org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
 {code}
try {
 zooKeeperSaslClient = new 
 ZooKeeperSaslClient(zookeeper/+addr.getHostName());
 }
 {code}
 This may have problems when admin wanted some customized principals like 
 zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
 not the host name.
 IMO, server principal also should be configurable as hadoop is doing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1467:
-

Attachment: ZOOKEEPER-1467.patch

Allows use of the 'zookeeper.clusterName' system property to specify the 
instance portion (the part after the slash character) of the Zookeeper server 
principal name.

 Server principal on client side is derived using hostname.
 --

 Key: ZOOKEEPER-1467
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
Reporter: Laxman
Assignee: Eugene Koontz
Priority: Blocker
  Labels: Security, client, kerberos, sasl
 Attachments: ZOOKEEPER-1467.patch


 Server principal on client side is derived using hostname.
 org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
 {code}
try {
 zooKeeperSaslClient = new 
 ZooKeeperSaslClient(zookeeper/+addr.getHostName());
 }
 {code}
 This may have problems when admin wanted some customized principals like 
 zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
 not the host name.
 IMO, server principal also should be configurable as hadoop is doing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13278097#comment-13278097
 ] 

Eugene Koontz commented on ZOOKEEPER-1467:
--

Hi Laxman, can you take a look at this patch and see if it's what you had in 
mind? 

Thanks, 
-Eugene

 Server principal on client side is derived using hostname.
 --

 Key: ZOOKEEPER-1467
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
Reporter: Laxman
Assignee: Eugene Koontz
Priority: Blocker
  Labels: Security, client, kerberos, sasl
 Attachments: ZOOKEEPER-1467.patch


 Server principal on client side is derived using hostname.
 org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
 {code}
try {
 zooKeeperSaslClient = new 
 ZooKeeperSaslClient(zookeeper/+addr.getHostName());
 }
 {code}
 This may have problems when admin wanted some customized principals like 
 zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
 not the host name.
 IMO, server principal also should be configurable as hadoop is doing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1467:
-

Release Note: Allow system property zookeeper.clusterName, if defined, to 
be used as the instance portion of zookeeper server's Kerberos principal name. 
Otherwise, server's hostname will be used.  (was: This patch does not yet 
contain any new tests.)

 Server principal on client side is derived using hostname.
 --

 Key: ZOOKEEPER-1467
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
Reporter: Laxman
Assignee: Eugene Koontz
Priority: Blocker
  Labels: Security, client, kerberos, sasl
 Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch


 Server principal on client side is derived using hostname.
 org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
 {code}
try {
 zooKeeperSaslClient = new 
 ZooKeeperSaslClient(zookeeper/+addr.getHostName());
 }
 {code}
 This may have problems when admin wanted some customized principals like 
 zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
 not the host name.
 IMO, server principal also should be configurable as hadoop is doing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1467:
-

Attachment: ZOOKEEPER-1467.patch

Improved patch with tests and comments.

 Server principal on client side is derived using hostname.
 --

 Key: ZOOKEEPER-1467
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3, 3.4.4, 3.5.0, 4.0.0
Reporter: Laxman
Assignee: Eugene Koontz
Priority: Blocker
  Labels: Security, client, kerberos, sasl
 Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch


 Server principal on client side is derived using hostname.
 org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
 {code}
try {
 zooKeeperSaslClient = new 
 ZooKeeperSaslClient(zookeeper/+addr.getHostName());
 }
 {code}
 This may have problems when admin wanted some customized principals like 
 zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but 
 not the host name.
 IMO, server principal also should be configurable as hadoop is doing.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Use a CountDownLatch within ClientCnxn to control access to outgoing packet 
queue: non-SASL packets must wait until SASL authentication has completed.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276988#comment-13276988
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Excuse me, I meant ClientCnxn:queuePacket(), not 
ClientCnxn:queueSaslPacket() in my 20:26 comment above.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1355) Add zk.updateServerList(newServerList)

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13277532#comment-13277532
 ] 

Eugene Koontz commented on ZOOKEEPER-1355:
--

Typo in src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml: 
jus should be just.

The documentation is good - perhaps it could make reference in the source code 
to where the client's server-selection logic is implemented 
(StaticHostProvider::updateServerList()).

i.e. provide a link to the source such as 
http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/client/StaticHostProvider.java?view=markup
 or 
https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/client/StaticHostProvider.java

The test cases seem to have a lot more cases than the documentation: would be 
nice to have the doc's examples correspond to the test cases.

 Add zk.updateServerList(newServerList) 
 ---

 Key: ZOOKEEPER-1355
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1355
 Project: ZooKeeper
  Issue Type: New Feature
  Components: c client, java client
Reporter: Alexander Shraer
Assignee: Alexander Shraer
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1355-ver10-1.patch, 
 ZOOKEEPER-1355-ver10-2.patch, ZOOKEEPER-1355-ver10-3.patch, 
 ZOOKEEPER-1355-ver10-4.patch, ZOOKEEPER-1355-ver10-4.patch, 
 ZOOKEEPER-1355-ver10.patch, ZOOKEEPER-1355-ver11-1.patch, 
 ZOOKEEPER-1355-ver11.patch, ZOOKEEPER-1355-ver12-1.patch, 
 ZOOKEEPER-1355-ver12-2.patch, ZOOKEEPER-1355-ver12-4.patch, 
 ZOOKEEPER-1355-ver12.patch, ZOOKEEPER-1355-ver13.patch, 
 ZOOKEEPER-1355-ver2.patch, ZOOKEEPER-1355-ver4.patch, 
 ZOOKEEPER-1355-ver5.patch, ZOOKEEPER-1355-ver6.patch, 
 ZOOKEEPER-1355-ver7.patch, ZOOKEEPER-1355-ver8.patch, 
 ZOOKEEPER-1355-ver9-1.patch, ZOOKEEPER-1355-ver9.patch, 
 ZOOKEEPER=1355-ver3.patch, ZOOOKEEPER-1355-test.patch, 
 ZOOOKEEPER-1355-ver1.patch, ZOOOKEEPER-1355.patch, 
 loadbalancing-more-details.pdf, loadbalancing.pdf


 When the set of servers changes, we would like to update the server list 
 stored by clients without restarting the clients.
 Moreover, assuming that the number of clients per server is the same (in 
 expectation) in the old configuration (as guaranteed by the current list 
 shuffling for example), we would like to re-balance client connections across 
 the new set of servers in a way that a) the number of clients per server is 
 the same for all servers (in expectation) and b) there is no 
 excessive/unnecessary client migration.
 It is simple to achieve (a) without (b) - just re-shuffle the new list of 
 servers at every client. But this would create unnecessary migration, which 
 we'd like to avoid.
 We propose a simple probabilistic migration scheme that achieves (a) and (b) 
 - each client locally decides whether and where to migrate when the list of 
 servers changes. The attached document describes the scheme and shows an 
 evaluation of it in Zookeeper. We also implemented re-balancing through a 
 consistent-hashing scheme and show a comparison. We derived the probabilistic 
 migration rules from a simple formula that we can also provide, if someone's 
 interested in the proof.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13276413#comment-13276413
 ] 

Eugene Koontz commented on ZOOKEEPER-1437:
--

Hi Patrick,

I think I understand you but I want to make sure:
 
Your idea is that ClientCnxn:queueSaslPacket() will use a 
java.util.concurrent.CountDownLatch to determine when SASL authentication is 
complete. The client's Main thread will await() on this latch. Meanwhile, the 
client's SendThread will be sending and receiving SASL packets until the 
ZooKeeperSaslClient has finished authenticating with the server. When SASL 
authentication is finished (successfully or not), the Send thread will 
countDown() the latch, and the Main thread will be able to continue, causing 
its packets to be enqueued on the outgoingQueue. 

NIOServerCnxn::doIO() will not need any changes - it will simply send and 
receive packets in the outgoingQueue's natural ordering, without regard to 
their type. But because of the latch in ClientCnxn:queueSaslPacket(), the 
packets will be ordered so that no permissions-requiring packets are sent 
before authentication completes.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (ZOOKEEPER-1455) there is no way to determine if a session is sasl authenticated or not

[Eugene Koontz (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13272016#comment-13272016
 ] 

Eugene Koontz commented on ZOOKEEPER-1455:
--

Currently, in the code for both server and client, we check for a non-null 
system property:

{{(System.getProperty(java.security.auth.login.config) != null)}} 

as a statement of intention to negotiate via SASL.




 there is no way to determine if a session is sasl authenticated or not
 --

 Key: ZOOKEEPER-1455
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1455
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Patrick Hunt
Priority: Critical

 The ZooKeeper interface provides no way to determine if the session is sasl 
 authenticated or not. There is an event sent to the watcher when the sasl 
 authentication completes, however there no way to determine if there is 
 intent to negotiate via sasl. As a result the event cannot be used to wait to 
 send messages until the authentication has completed. see HADOOP-8315

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

-pass simply a boolean flag to doIO() and doTransport() rather than entire 
Cnxn.SendThread - will be faster too, since 
clientTunneledAuthenticationInProgress will only be called once per 
doTransport() call.
-move operationRequiresPermissions() to ZooDefs.java and make static
-wrap new LOG.debug() message inside a (LOG.isDebugEnabled()) conditional.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

Modify doIO() so that if SASL authentication is in process, defer sending of 
packets in the outgoingQueue that are subject to permissions-checking until 
SASL authentication is complete, per Patrick's recommendation.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (ZOOKEEPER-1437) Client uses session before SASL authentication complete

[Eugene Koontz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eugene Koontz updated ZOOKEEPER-1437:
-

Attachment: ZOOKEEPER-1437.patch

As with patches in March, modify tests to remove now-unnecessary sleeps, and 
set authInitFailed = true where needed.

 Client uses session before SASL authentication complete
 ---

 Key: ZOOKEEPER-1437
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1437
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.3
Reporter: Thomas Weise
Assignee: Eugene Koontz
 Fix For: 3.4.4, 3.5.0

 Attachments: ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, ZOOKEEPER-1437.patch, 
 ZOOKEEPER-1437.patch


 Found issue in the context of hbase region server startup, but can be 
 reproduced w/ zkCli alone.
 getData may occur prior to SaslAuthenticated and fail with NoAuth. This is 
 not expected behavior when the client is configured to use SASL.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira