lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pascal Proulx (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-12371) SecurityConfHandlerLocal fails to read back security.json meta version (SecurityConfig.getVersion() always -1), never increased
Date Thu, 17 May 2018 18:49:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-12371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479536#comment-16479536
] 

Pascal Proulx edited comment on SOLR-12371 at 5/17/18 6:48 PM:
---------------------------------------------------------------

For reference, here is what the zookeeper handler does: org.apache.solr.handler.admin.SecurityConfHandlerZk.getSecurityConfig(boolean)
{code:java}
  @Override
  public SecurityConfig getSecurityConfig(boolean getFresh) {
    ZkStateReader.ConfigData configDataFromZk = cores.getZkController().getZkStateReader().getSecurityProps(getFresh);
    return configDataFromZk == null ?
        new SecurityConfig() :
        new SecurityConfig().setData(configDataFromZk.data).setVersion(configDataFromZk.version);
  }
{code}
So presumably org.apache.solr.handler.admin.SecurityConfHandlerLocal.getSecurityConfig(boolean)
is missing a call to setVersion after calling setData:
{code:java}
  @Override
  public SecurityConfig getSecurityConfig(boolean getFresh) {
    if (Files.exists(securityJsonPath)) {
      try (InputStream securityJsonIs = Files.newInputStream(securityJsonPath)) {
        return new SecurityConfig().setData(securityJsonIs);
      } catch (Exception e) {
        throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Failed opening
existing security.json file: " + securityJsonPath, e);
      }
    }
    return new SecurityConfig();
  }
{code}
 (or SecurityConfig could encapsulate the initialization of version from data, but I have
no idea if that can be generalized there)

 


was (Author: pplx):
For reference, here is what the zookeeper handler does: org.apache.solr.handler.admin.SecurityConfHandlerZk.getSecurityConfig(boolean)
{code:java}
  @Override
  public SecurityConfig getSecurityConfig(boolean getFresh) {
    ZkStateReader.ConfigData configDataFromZk = cores.getZkController().getZkStateReader().getSecurityProps(getFresh);
    return configDataFromZk == null ?
        new SecurityConfig() :
        new SecurityConfig().setData(configDataFromZk.data).setVersion(configDataFromZk.version);
  }
{code}
So presumably org.apache.solr.handler.admin.SecurityConfHandlerLocal.getSecurityConfig(boolean)
is missing a call to setVersion after calling setData:
{code:java}
  @Override
  public SecurityConfig getSecurityConfig(boolean getFresh) {
    if (Files.exists(securityJsonPath)) {
      try (InputStream securityJsonIs = Files.newInputStream(securityJsonPath)) {
        return new SecurityConfig().setData(securityJsonIs);
      } catch (Exception e) {
        throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, "Failed opening
existing security.json file: " + securityJsonPath, e);
      }
    }
    return new SecurityConfig();
  }
{code}
 (or SecurityConfig should encapsulate the initialization of version from data)

 

> 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 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message