[
https://issues.apache.org/jira/browse/SOLR-12371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817470#comment-16817470
]
Jan Høydahl commented on SOLR-12371:
------------------------------------
Managed to reproduce. See [GitHub Pull Request
#646|https://github.com/apache/lucene-solr/pull/646] for a test that fails due
to this caching. I solved it by requiring version>0 in order to cache. It
effectively will never be true for local mode since version is always -1 (or 0
after an edit).
Appreciate if you could test the patch in your environment, plan to commit next
week.
> SecurityConfHandlerLocal fails to read back security.json meta version
> (SecurityConfig.getVersion() always -1), never increased
> -------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-12371
> URL: https://issues.apache.org/jira/browse/SOLR-12371
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: JSON Request API, security
> Affects Versions: 6.6.3
> Reporter: Pascal Proulx
> Assignee: Jan Høydahl
> Priority: Major
> Fix For: 8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Hello again,
> We use 6.6.3 and I was trying to update my security.json (in solr home,
> non-zookeeper) using:
> {code:java}
> curl -u myuser:mypass -H 'Content-type:application/json' -d
> '{"set-user-role":{"dummy":"dummy"}}'
> http://localhost:8080/solr/admin/authorization
> {code}
> The first time this is called, the security.json is written AND reloaded in
> memory correctly. The output json then contains at the end:
> {code:java}
> "":{"v":0}
> {code}
> However, subsequent calls using the same command, no matter the users
> specifed, always output the same meta version, 0.
> The result is that the the security.json file is correctly updated, but the
> RuleBasedAuthorizationPlugin is never reloaded in memory, so the new settings
> never take effect.
> The version never increases, so this condition in
> org.apache.solr.core.CoreContainer.initializeAuthorizationPlugin always
> returns and memory plugin reload is skipped:
> {code:java}
> if (old != null && old.getZnodeVersion() == readVersion(authorizationConf)) {
> return;
> }
> {code}
> The core of the issue is somewhere in
> org.apache.solr.handler.admin.SecurityConfHandler.doEdit:
> {code:java}
> SecurityConfig securityConfig = getSecurityConfig(true);
> Map<String, Object> data = securityConfig.getData();
> Map<String, Object> latestConf = (Map<String, Object>) data.get(key);
> if (latestConf == null) {
> throw new SolrException(SERVER_ERROR, "No configuration present for "
> + key);
> }
> List<CommandOperation> commandsCopy = CommandOperation.clone(ops);
> Map<String, Object> out =
> configEditablePlugin.edit(Utils.getDeepCopy(latestConf, 4) , commandsCopy);
> if (out == null) {
> List<Map> errs = CommandOperation.captureErrors(commandsCopy);
> if (!errs.isEmpty()) {
> rsp.add(CommandOperation.ERR_MSGS, errs);
> return;
> }
> log.debug("No edits made");
> return;
> } else {
> if(!Objects.equals(latestConf.get("class") , out.get("class"))){
> throw new SolrException(SERVER_ERROR, "class cannot be modified");
> }
> Map meta = getMapValue(out, "");
> meta.put("v", securityConfig.getVersion()+1);//encode the expected
> zkversion
> data.put(key, out);
>
> if(persistConf(securityConfig)) {
> securityConfEdited();
> return;
> }
> }
> {code}
> In my case, getSecurityConfig(true) delegates to
> org.apache.solr.handler.admin.SecurityConfHandlerLocal.getSecurityConfig(boolean)
> But the instance variable SecurityConfig.version is never set to anything
> other than -1; it is not read back from security.json in other words the data
> map, such that
> {code:java}
> meta.put("v", securityConfig.getVersion()+1);//encode the expected zkversion
> {code}
> always puts a value of 0 for the version, leading to the aforementioned
> memory reload skip.
> There does not seem to be any code calling SecurityConfig.setVersion anywhere
> or any of SecurityConfig's methods updating the version variable.
> The only code that does call it is in the SecurityConfHandlerZk for
> zookeeper, but we are not using zookeeper.
> Ultimately, I can't seem to use the set-user-role command because of this. I
> hope this is just a duplicate. Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
