[ 
https://issues.apache.org/jira/browse/SOLR-12371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pascal Proulx updated SOLR-12371:
---------------------------------
    Description: 
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

  was:
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 command because of this. I hope 
this is just a duplicate. Thanks


> 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
>            Priority: Major
>
> 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

Reply via email to