[jira] [Commented] (ZOOKEEPER-2282) chroot not stripped from path in asynchronous callbacks
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939717#comment-16939717 ] Hudson commented on ZOOKEEPER-2282: --- SUCCESS: Integrated in Jenkins build Zookeeper-trunk-single-thread #553 (See [https://builds.apache.org/job/Zookeeper-trunk-single-thread/553/]) ZOOKEEPER-2282: C Client: chroot not stripped in asynchronous callbacks (andor: rev 1e7fae31af634ccfb85cde17fa634d188145b9b7) * (edit) zookeeper-client/zookeeper-client-c/src/zookeeper.c * (edit) zookeeper-client/zookeeper-client-c/tests/TestClient.cc > chroot not stripped from path in asynchronous callbacks > --- > > Key: ZOOKEEPER-2282 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2282 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.6, 3.5.0 > Environment: Centos 6.6 >Reporter: Andrew Grasso >Assignee: Andrew Grasso >Priority: Critical > Labels: pull-request-available > Fix For: 3.6.0, 3.5.7 > > Attachments: ZOOKEEPER-2282.patch > > Original Estimate: 1h > Time Spent: 50m > Remaining Estimate: 10m > > Callbacks passed to [zoo_acreate], [zoo_async], and [zoo_amulti] (for create > ops) are called on paths that include the chroot. This is analagous to issue > 1027, which fixed this bug for synchronous calls. > I've created a patch to fix this in trunk -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3509) Revisit log format
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-3509: -- Labels: pull-request-available (was: ) > Revisit log format > -- > > Key: ZOOKEEPER-3509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3509 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Zili Chen >Assignee: Zili Chen >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0 > > > Currently ZooKeeper mixes up different log format and even a number of log > statements are buggy. It is an opportunity that we revisit log format in > ZooKeeper and do a pass to fix all log format related issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939576#comment-16939576 ] Mohammad Arshad commented on ZOOKEEPER-3561: 1. In ZOOKEEPER-1634 all properties names are in context of SASL. Now the context is broad and 3.6.0 is not released yet so i think we can change the property names. Giving new name to properties. enforce.auth.enabled and enforce.auth.scheme 2. There is no need to do special handling for allowSaslFailedClients scenario. When enforce authentication is enabled allowSaslFailedClients is implied to be false. So we can take this as false in case enforce.auth.enabled=true Moreover allowSaslFailedClients seems to be a testing property. It makes no sense to enable enforce authentication and allow failed SASL authentication. If someone wants to allow failed authentication he will not enable enforce authentication and vice versa. 3. I think it may not be required to introduce new response code SESSIONCLOSEDREQUIRESASLAUTH. Exploring bit more if we can use AUTHFAILED > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939541#comment-16939541 ] Michael Han commented on ZOOKEEPER-3558: sounds good, thanks for driving this [~arshad.mohammad]. > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.7 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3559) Update Jackson to 2.9.10
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939510#comment-16939510 ] Hudson commented on ZOOKEEPER-3559: --- SUCCESS: Integrated in Jenkins build Zookeeper-trunk-single-thread #552 (See [https://builds.apache.org/job/Zookeeper-trunk-single-thread/552/]) ZOOKEEPER-3559: Update Jackson to 2.9.10 (nkalmar: rev 63a825372eaa745cf117f53b0f9b263a0db05a4f) * (edit) build.xml * (edit) pom.xml > Update Jackson to 2.9.10 > > > Key: ZOOKEEPER-3559 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3559 > Project: ZooKeeper > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.6 > > Time Spent: 1h > Remaining Estimate: 0h > > Jackson should be updated to the latest version to pick up a fix for > CVE-2019-14540 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-1467:
--
Labels: Security client kerberos pull-request-available sasl (was:
Security client kerberos sasl)
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, pull-request-available, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3559) Update Jackson to 2.9.10
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár updated ZOOKEEPER-3559: -- Fix Version/s: 3.5.6 3.6.0 > Update Jackson to 2.9.10 > > > Key: ZOOKEEPER-3559 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3559 > Project: ZooKeeper > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.6 > > Time Spent: 1h > Remaining Estimate: 0h > > Jackson should be updated to the latest version to pick up a fix for > CVE-2019-14540 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3559) Update Jackson to 2.9.10
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár resolved ZOOKEEPER-3559. --- Resolution: Fixed > Update Jackson to 2.9.10 > > > Key: ZOOKEEPER-3559 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3559 > Project: ZooKeeper > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.6 > > Time Spent: 1h > Remaining Estimate: 0h > > Jackson should be updated to the latest version to pick up a fix for > CVE-2019-14540 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3559) Update Jackson to 2.9.10
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár reassigned ZOOKEEPER-3559: - Assignee: Colm O hEigeartaigh > Update Jackson to 2.9.10 > > > Key: ZOOKEEPER-3559 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3559 > Project: ZooKeeper > Issue Type: Bug >Reporter: Colm O hEigeartaigh >Assignee: Colm O hEigeartaigh >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Jackson should be updated to the latest version to pick up a fix for > CVE-2019-14540 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (ZOOKEEPER-3561) Generalize target authentication scheme for ZooKeeper authentication enforcement.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mohammad Arshad reassigned ZOOKEEPER-3561: -- Assignee: Mohammad Arshad > Generalize target authentication scheme for ZooKeeper authentication > enforcement. > - > > Key: ZOOKEEPER-3561 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3561 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: Michael Han >Assignee: Mohammad Arshad >Priority: Major > > ZOOKEEPER-1634 introduced an option to allow user enforce authentication for > ZooKeeper clients, but the enforced authentication scheme in committed > implementation was SASL only. > This JIRA is to generalize the authentication scheme such that the > authentication enforcement on ZooKeeper clients could work with any supported > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3558) Support authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939326#comment-16939326 ] Mohammad Arshad commented on ZOOKEEPER-3558: I will work on ZOOKEEPER-3561 . After ZOOKEEPER-3561 is committed will raise PR to backport to branch-3.5 > Support authentication enforcement > -- > > Key: ZOOKEEPER-3558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3558 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Mohammad Arshad >Assignee: Mohammad Arshad >Priority: Major > Fix For: 3.5.7 > > Attachments: ZOOKEEPER-3558-01.patch > > > Provide authentication enforcement in ZooKeeper that is backward compatible > and can work for any authentication scheme, can work even with custom > authentication schemes. > *Problems:* > 1. Currently server is starting with default authentication > providers(DigestAuthenticationProvider, IPAuthenticationProvider). These > default authentication providers are not really secure. > 2. ZooKeeper server is not checking whether authentication is done or not > before performing any user operation. > *Solutions:* > 1. We should not start any authentication provider by default. But this would > be backward incompatible change. So we can provide configuration whether to > start default authentication provides are not. > By default we can start these authentication providers. > 2. Before any user operation server should check whether authentication > happened or not. At least client must be authenticated with one > authentication scheme. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939312#comment-16939312
]
Sujith Simon commented on ZOOKEEPER-1467:
-
[~arshad.mohammad] I would like to raise a PR for this. Will raise the PR
soon :)
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Joseph Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
