[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549-5.patch Latest patch that includes all the changes > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549-3.patch, > ZOOKEEPER-2549-3.patch, ZOOKEEPER-2549-4.patch, ZOOKEEPER-2549-5.patch, > ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15720487#comment-15720487 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- I have updated PR with changes to latest review comments > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549-3.patch, > ZOOKEEPER-2549-3.patch, ZOOKEEPER-2549-4.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15648561#comment-15648561 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- the test failure is irrelevant > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549-3.patch, > ZOOKEEPER-2549-3.patch, ZOOKEEPER-2549-4.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549-4.patch Latest patch with addressed review comments > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549-3.patch, > ZOOKEEPER-2549-3.patch, ZOOKEEPER-2549-4.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549-3.patch Forgot --no-prefix, so previous patch did not apply :( > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549-3.patch, > ZOOKEEPER-2549-3.patch, ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch, > zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549-3.patch Uploading patch manually, looks like pre commit builds based on PRs do not work properly > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549-3.patch, > ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15637895#comment-15637895 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- Submitted PR that addresses review comments > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1563#comment-1563 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- [~rgs] - One comment regarding your comment on double instantiation. It will happen only in case of unit tests. I will certainly make a change to avoid double instantiation even in that case, but code-wise it will look a bit "uglier". Will post new patch soon > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15636923#comment-15636923 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- Thank you very much [~rgs] for review > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15634884#comment-15634884 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- Ping again. It has been 6 weeks already [~phunt], [~rgs] - Could you please review the patch, as it seems you are the most familiar with the code in question. > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509-1.patch, ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, > ZOOKPEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15634879#comment-15634879 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- Ping again. It has been about 6 weeks. It is really an issue at least with Netty implementation. [~phunt], [~rgs] - Could you please review the patch, as it seems you are the most familiar with the code in question. > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15514864#comment-15514864 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- [~phunt], [~rgs] - Could you please review the patch, as it seems you are the most familiar with the code in question. > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509-1.patch, ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, > ZOOKPEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15514862#comment-15514862 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- [~phunt], [~rgs] - Could you please review the patch, as it seems you are the most familiar with the code in question. > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15514066#comment-15514066 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- Thank you very much [~hanm] for the review. I thought you are the one :). > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509-1.patch, ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, > ZOOKPEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15514063#comment-15514063 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- Thank you very much [~hanm] for the review. I thought you are the one :). > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513854#comment-15513854 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- [~hanm] - just wonder if anything else we can do here, or it is good to go? > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15513850#comment-15513850 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- [~hanm] - just wonder if anything else we can do here, or it is good to go? > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509-1.patch, ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, > ZOOKPEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15495020#comment-15495020 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- Thank you [~hanm] for reviewing it. I have addressed your review comments. Attached updated patch. > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509-1.patch, ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, > ZOOKPEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2509: -- Attachment: ZOOKEEPER-2509-1.patch Addressing review comments > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509-1.patch, ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, > ZOOKPEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489519#comment-15489519
]
Yuliya Feldman edited comment on ZOOKEEPER-2549 at 9/14/16 5:57 AM:
Addressing review comments:
Removed {code} if (LOG.isDebugEnabled()) {code}
Added comments
was (Author: yufeldman):
Addressing review comments
> As NettyServerCnxn.sendResponse() allows all the exception to bubble up it
> can stop main ZK requests processing thread
> --
>
> Key: ZOOKEEPER-2549
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.1
>Reporter: Yuliya Feldman
>Assignee: Yuliya Feldman
> Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch,
> ZOOKEEPER-2549.patch, zookeeper-2549-1.patch
>
>
> As NettyServerCnxn.sendResponse() allows all the exception to bubble up it
> can stop main ZK requests processing thread and make Zookeeper server look
> like it is hanging, while it just can not process any request anymore.
> Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() ,
> convert them to IOException and allow it propagating up
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Comment: was deleted (was: Sure - removed if (LOG.isDebugEnabled()) Added comments) > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489522#comment-15489522 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- Sure - removed if (LOG.isDebugEnabled()) Added comments > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549-2.patch Addressing review comments > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549-2.patch, ZOOKEEPER-2549.patch, > ZOOKEEPER-2549.patch, zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488960#comment-15488960 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- [~hanm] Could you review this JIRA as well, as it actually triggered [JIRA-2549|https://issues.apache.org/jira/browse/ZOOKEEPER-2549] > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, ZOOKPEEPER-2509.patch, > leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488893#comment-15488893 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- 1. Sorry, which class are you referring to for debug ? 2. Yes, I will add comments regarding use of reflection to support Mock classes - true it was added for testability. > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch, > zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: zookeeper-2549-1.patch Addressed comments: 1. Added missing Exception Handling to NIOServerCnxn 2. Enhanced Unit tests to test both NIO and Netty 3. Unsetting properties after tests are done > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch, > zookeeper-2549-1.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15469002#comment-15469002 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- >>> Should we also do similar updates to NIOServerCnx which swallows every >>> exception instead of converting them to IOException, for the purpose of >>> consistency? Sure >>> Also, for tests, might be good to reset system properties in teardown via >>> System.clearProperty. Yep - will do > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549.patch Reattaching just to trigger the build > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549.patch, ZOOKEEPER-2549.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15463514#comment-15463514 ] Yuliya Feldman commented on ZOOKEEPER-2509: --- Hmmm..., looks like until trunk tests failures are fixed hard to get a clean build > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, ZOOKPEEPER-2509.patch, > leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2509: -- Attachment: ZOOKPEEPER-2509.patch Sorry - forgot --no-prefix. Updated one > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, ZOOKPEEPER-2509.patch, > leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2509: -- Attachment: ZOOKEEPER-2509.patch Updated patch with correct formatting. [~tdunning] - please review, since it includes removing setting zkServer to null. > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509.patch, ZOOKEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2509) Secure mode leaks memory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2509: -- Attachment: ZOOKEEPER-2509.patch Updated patch with correct formatting. [~tdunning] - please review, since it includes removing setting zkServer to null. > Secure mode leaks memory > > > Key: ZOOKEEPER-2509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.1, 3.5.2 >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.3, 3.6.0 > > Attachments: > 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, > ZOOKEEPER-2509.patch, leak-patch.patch > > > The Netty connection handling logic fails to clean up watches on connection > close. This causes memory to leak. > I will have a repro script available soon and a fix. I am not sure how to > build a unit test since we would need to build an entire server and generate > keys and such. Advice on that appreciated. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15461233#comment-15461233 ] Yuliya Feldman commented on ZOOKEEPER-2549: --- Really very strange test failures - completely unrelated. Could it be some issues with the cluster during the run? > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2549: -- Attachment: ZOOKEEPER-2549.patch > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread > -- > > Key: ZOOKEEPER-2549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman > Attachments: ZOOKEEPER-2549.patch > > > As NettyServerCnxn.sendResponse() allows all the exception to bubble up it > can stop main ZK requests processing thread and make Zookeeper server look > like it is hanging, while it just can not process any request anymore. > Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , > convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2549) As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread
Yuliya Feldman created ZOOKEEPER-2549: - Summary: As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread Key: ZOOKEEPER-2549 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2549 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.1 Reporter: Yuliya Feldman Assignee: Yuliya Feldman As NettyServerCnxn.sendResponse() allows all the exception to bubble up it can stop main ZK requests processing thread and make Zookeeper server look like it is hanging, while it just can not process any request anymore. Idea is to catch all the exceptions in NettyServerCnxn.sendResponse() , convert them to IOException and allow it propagating up -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2509) Secure mode leaks memory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15437358#comment-15437358
]
Yuliya Feldman commented on ZOOKEEPER-2509:
---
-1
Following line:
{code}
+zkServer = null;
{code}
is causing NPE later on - race condition is between Netty connection going away
and message in the queue getting processed
> Secure mode leaks memory
>
>
> Key: ZOOKEEPER-2509
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2509
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.1, 3.5.2
>Reporter: Ted Dunning
>Assignee: Ted Dunning
> Fix For: 3.5.3
>
> Attachments:
> 0001-Updated-patch-for-Netty-leak-testing-to-trunk.patch, leak-patch.patch
>
>
> The Netty connection handling logic fails to clean up watches on connection
> close. This causes memory to leak.
> I will have a repro script available soon and a fix. I am not sure how to
> build a unit test since we would need to build an entire server and generate
> keys and such. Advice on that appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1045) Quorum Peer mutual authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15300462#comment-15300462 ] Yuliya Feldman commented on ZOOKEEPER-1045: --- [[~rakeshr] I would be interested to extend pluggable authentication not just to client/server but also server/server. I can certainly do it as a follow up to your JIRA, but would be greta at least to coordinate. > Quorum Peer mutual authentication > - > > 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 > Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch, > 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-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-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15206738#comment-15206738 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [~fpj] considering you marked this one as a Blocker (not sure if by mistake or not). Could you please review it? > 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 >Priority: Blocker > Fix For: 3.5.2, 3.6.0 > > 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15097036#comment-15097036 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [[~fpj] Would you have time now to review? - since 3.4.7 came and gone > 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 > Fix For: 3.5.2, 3.6.0 > > 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971193#comment-14971193 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [~fournc] It looks like we don't get any response from [~ekoontz]. It there anybody else that could pick up to review this? I would truly appreciate it. > 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971262#comment-14971262 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- Thank you [~fpj] > 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 > Fix For: 3.5.2, 3.6.0 > > 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-2289) Support use of SASL "auth-int" and "auth-conf" quality of protection.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14952495#comment-14952495 ] Yuliya Feldman commented on ZOOKEEPER-2289: --- This JIRA is related to ZOOKEEPER-2159 Ideally the end goal to support all QOPs with each SASL implementation > Support use of SASL "auth-int" and "auth-conf" quality of protection. > - > > Key: ZOOKEEPER-2289 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2289 > Project: ZooKeeper > Issue Type: New Feature > Components: java client, server >Reporter: Chris Nauroth >Priority: Trivial > > The current codebase supports use of SASL for authenticating connections, but > it does not allow specifying the desired SASL Quality of Protection (QOP). > It always uses the default QOP, which is "auth" (authentication only). This > issue proposes to support the full set of available QOP settings by adding > support for "auth-int" (authentication and integrity) and "auth-conf" > (authentication and integrity and privacy/encryption). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14537330#comment-14537330 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [~ekoontz] Any news? Did you have a chance to review my changes/replies and test with Kerberos? 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14523624#comment-14523624 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [~ekoontz] I have updated reviewboard and replied to all the comments you have made. Did you have a chance to test Kerberos and do you mind give another pass on review request. Thanks. 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14519765#comment-14519765 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [~ekoontz] I have posted patch that addresses majority of your comments. Thank you for the review 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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511250#comment-14511250
]
Yuliya Feldman commented on ZOOKEEPER-2159:
---
Thank you Eugene
Here is JAAS config I used for Kerberos testing.
Additional property is
authMech=GSSAPI
{code}
Server {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab=path_to_keytab
storeKey=true
useTicketCache=false
debug=true
authMech=GSSAPI
principal=principal;
};
Client {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true
renewTGT=true
authMech=GSSAPI
debug=true
doNotPrompt=true;
};
{code}
Please do let me know results of your testing, since I also tested it with
Kerberos setup.
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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507220#comment-14507220 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- [~ekoontz] Thank you 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14485584#comment-14485584 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- I have added review request for what we have now: https://reviews.apache.org/r/32979 It would be great to get feedback 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] [Created] (ZOOKEEPER-2159) Pluggable SASL Authentication
Yuliya Feldman created ZOOKEEPER-2159: - Summary: 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 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] [Updated] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2159: -- Attachment: PluggableZookeeperAuthentication.pdf This is a Draft of a proposal for Pluggable SASL Authentication in Zookeeper. Would be nice to get initial feedback on this. 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.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] [Updated] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuliya Feldman updated ZOOKEEPER-2159: -- Attachment: PluggableZookeeperAuthentication (1).pdf Updated Design Doc with Backward Compatibility, Testing section 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
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14484541#comment-14484541 ] Yuliya Feldman commented on ZOOKEEPER-2159: --- Yes - you are right on the first part. It may imply that weaker one can be used while original intent was to use stronger one. I listed negotiation as an improvement on top of the proposal, since it will require more substantial changes in handling sasl request/response between server and client. 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-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779407#comment-13779407
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
I am looking into failure
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.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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779501#comment-13779501
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
I have retested it again and I don't see any test failure. Plus all trunk
builds were successful after this check in. On top of it during znode creation
code from this JIRA's patch is not even executed. Do you consistently see the
failure or it one of?
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.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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13779566#comment-13779566
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Ok, I was finally able to repro your failure - problem in tests ordering. Your
order was different from others that caused failure. Since I was adding a test
case on Eugene's request to test unauthenticated Client I set
zookeeper.sasl.client to false and did not reenable it back at the end of
the test. This caused Client from following test (testAuth) to be not
authenticated and subsequently failing.
I fixed test to set zookeeper.sasl.client to true at the end of my test and
it should fix your issue. Will submit patch shortly.
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.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] [Updated] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Attachment: ZOOKEEPER-1759-1.patch
Additional to fix testx
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.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] [Updated] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Attachment: ZOOKEEPER-1759.patch
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13777222#comment-13777222
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
I have updated the patch with additional test for non-SASL-authenticated user,
or rather SASL unauthenticated client.
Thanks.
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13778385#comment-13778385
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Sorry, Could not reply earlier - was out whole day.
@Eugene - Since this one is committed should I submit another JIRA to change
name of the property, or submit another patch on this JIRA?
@Flavio I am not exactly following. In the JIRA you are referring to you were
proposing to put property into QuorumConfig object, is it? I did not find
anything the patch(es) that was related to configuration
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776565#comment-13776565
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Thank you Eugene for your comments
Regarding #1 - I agree that name readUser may not be a good one - because it
is up to the ACL creator to expose particular operation.
Regarding #2 - It does add authentication restrictions, not authorization ones.
Today only superUser can do whatever with znode that has restricted ACLs. If I
put world anyone for readable - no Authentication will be involved at all.
Here is the snippet from PrepRequestProcessor:
{code}
for (ACL a : acl) {
Id id = a.getId();
if ((a.getPerms() perm) != 0) {
if (id.getScheme().equals(world)
id.getId().equals(anyone)) {
return;
}
AuthenticationProvider ap = ProviderRegistry.getProvider(id
.getScheme());
if (ap != null) {
for (Id authId : ids) {
if (authId.getScheme().equals(id.getScheme())
ap.matches(authId.getId(), id.getId())) {
return;
}
}
}
}
}
{code}
As you can see if it is world anyone - No authentication is checked at all.
Regarding unit tests - I did add them - should be in the patch
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13776810#comment-13776810
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Sure. I will add test for non-SASL authenticated user.
Thanks.
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774295#comment-13774295
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Is anything else needs to be done on my side to have this patch committed?
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] [Updated] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Description:
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
was:
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
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
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
--
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-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Attachment: ZOOKEEPER-1759.patch
ZOOKEEPER-1759.patch
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
Attachments: 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
--
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-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Description:
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 acl = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE,
Ids.AUTH_IDS);
ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
{code}
will need to do
{code:java}
ACL acl = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE,
Ids.AUTH_IDS);
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.
was:
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
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
Attachments: 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 acl = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE,
Ids.AUTH_IDS);
ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
{code}
will need to do
{code:java}
ACL acl = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE,
Ids.AUTH_IDS);
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] [Updated] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Description:
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.
was:
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 acl = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE,
Ids.AUTH_IDS);
ACL(Perms.READ, Ids.ANYONE_ID_UNSAFE);
{code}
will need to do
{code:java}
ACL acl = new ACL(Perms.ADMIN | Perms.CREATE | Perms.WRITE | Perms.DELETE,
Ids.AUTH_IDS);
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.
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
Attachments: 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] [Updated] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Attachment: ZOOKEEPER-1759.patch
Latest
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
Attachments: 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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771426#comment-13771426
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Sure. I thought I did, but apparently it did not work.
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
Attachments: 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] [Updated] (ZOOKEEPER-1759) Adding ability to allow READ operations for authenticated users, versus keeping ACLs wide open for READ
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuliya Feldman updated ZOOKEEPER-1759:
--
Attachment: ZOOKEEPER-1759.patch
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
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771457#comment-13771457
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
Resubmitted svn patch instead of git one. Hopefully this will work.
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
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
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771498#comment-13771498
]
Yuliya Feldman commented on ZOOKEEPER-1759:
---
I don't quite understand how this failure is related to the patch:
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/TestReconfig.cc:488:
Assertion: assertion failed [Expression: found != string::npos]
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
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
