Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-12371

Editing authorization config via REST API fails in standalone mode due to version caching

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 6.6.3
    • Fix Version/s: 7.7.2, 8.1
    • Component/s: JSON Request API, security
    • Labels:
      None

      Description

      Hello again,

      We use 6.6.3 and I was trying to update my security.json (in solr home, non-zookeeper) using:

      curl -u myuser:mypass -H 'Content-type:application/json' -d '{"set-user-role":{"dummy":"dummy"}}' http://localhost:8080/solr/admin/authorization
      

      The first time this is called, the security.json is written AND reloaded in memory correctly. The output json then contains at the end:

      "":{"v":0}
      

      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:

      if (old != null && old.getZnodeVersion() == readVersion(authorizationConf)) {
        return;
      }
      

      The core of the issue is somewhere in org.apache.solr.handler.admin.SecurityConfHandler.doEdit:

            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;
              }
            }
      

      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

      meta.put("v", securityConfig.getVersion()+1);//encode the expected zkversion
      

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                janhoy Jan Høydahl
                Reporter:
                pplx Pascal Proulx
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 20m
                  20m