[
https://issues.apache.org/jira/browse/SOLR-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14710861#comment-14710861
]
Per Steffensen commented on SOLR-7890:
--------------------------------------
In general, looks good!
Like the JavaDoc you added to {{VMParamsAllAndReadonlyDigestZkACLProvider}}
Remember update documentation on cwiki, if you find appropriate.
Maybe {{ZkZnodeProtection}} should be closer connected to
{{VMParamsAllAndReadonlyDigestZkACLProvider}} (e.g. inner class). It is only
when you actively decide to use {{VMParamsAllAndReadonlyDigestZkACLProvider}}
as your ACL-provider that {{ZkZnodeProtection}} is used. Default is still
{{DefaultZkACLProvider}} which does not take {{ZkZnodeProtection}} into
consideration. When {{ZkZnodeProtection}} is a separate standalone class, you
might be surprised that it is actually only used when you actively pick
{{VMParamsAllAndReadonlyDigestZkACLProvider}}.
I believe a few versions of Solr have already been released including
SOLR-4580. Therefore you need to think about if Solr behaves appropriate when
upgrading to a release including SOLR-7890. Lets say you have a Solr (version
before SOLR-7890) installation where you have turned on
{{VMParamsAllAndReadonlyDigestZkACLProvider}}, so that all your znodes are
ACL'ed with all/admin/admin and read-only/client/client.
* If you do nothing, but read the release-notes including SOLR-7890
description, you might expect that the ACL's of security.json (already exists
in ZK when you start up your new Solr) is automatically changed to only have
ACL all/admin/admin (and not read-only/client/client anymore). That will not
happen.
* Same problem if you upgrade to the new Solr and provide an explicit
{{-DzkProtectedPaths}} including znodes that already exist
There is a consistency issue here, that we at least need to be explicit about.
You will not end up with the "expected" ACL's on protected-paths if those
znodes already exist when you upgrade to an SOLR-7890 Solr. This problem also
existed before SOLR-7890, but only if you changed your ACL-provider
implementation, and in that case you have a better chance of guessing the issue
as an administrator of the system. So I think this problem becomes more urgent
to document/solve as we introduce SOLR-7890.
Same kind of problem will occur, if we in a later release add to the
default-list
{{VMParamsAllAndReadonlyDigestZkACLProvider.DEFAULT_PROTECTED_PATHS}}
I do know if we should just document this "behavior", or make a solution. In
case we want to make a solution, we might want to have some code that can run
through the entire znode-structure and ensure that the ACL's are as they are
supposed to be according to current code and configuration. Then run that code
when Solr nodes start and/or as part of upgrading Solr-versions.
Sorry, that I do not have time for more than this quick comment.
> By default require admin rights to access /security.json in ZK
> --------------------------------------------------------------
>
> Key: SOLR-7890
> URL: https://issues.apache.org/jira/browse/SOLR-7890
> Project: Solr
> Issue Type: Sub-task
> Components: security
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Fix For: Trunk
>
> Attachments: SOLR-7890.patch
>
>
> Perhaps {{VMParamsAllAndReadonlyDigestZkACLProvider}} should by default
> require admin access for read/write of {{/security.json}}, and other
> sensitive paths. Today this is left to the user to implement.
> Also, perhaps factor out the already-known sensitive paths into a separate
> class, so that various {{ACLProvider}} implementations can get a list of
> paths that should be admin-only, read-only etc from one central place. Then
> 3rd party impls pulling ZK creds from elsewhere will still do the right thing
> in the future if we introduce other sensitive Znodes...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
