[jira] [Commented] (SOLR-12976) Unify RedactionUtils and metrics hiddenSysProps settings

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (SOLR-12976) Unify RedactionUtils and metrics hiddenSysProps settings

JIRA jira@apache.org

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

Gus Heck commented on SOLR-12976:
---------------------------------

Of the top of my head:
 # Add a field to a schema via the schema api that has a value ${java.version} for the field name or default value (name tested, definately works) Any query returning a document with the field or api call listing fields may expose the result
 # Configure at type in schema.xml via the api with an attribute that's not too sensitive 
{code:java}
{
  "add-field-type" : {
     "name":"myNewTxtField",
     "class":"solr.TextField",
     "positionIncrementGap":"100",
     "analyzer" : {
        "charFilters":[{
           "class":"solr.PatternReplaceCharFilterFactory",
           "replacement":"${java.version}",
           "pattern":"([a-zA-Z])\\\\1+" }],
        "tokenizer":{
           "class":"solr.WhitespaceTokenizerFactory" },
        "filters":[{
           "class":"solr.WordDelimiterFilterFactory",
           "preserveOriginal":"0" }]}}
}

and then request the schema from the API
      {
        "name":"myNewTxtField",
        "class":"solr.TextField",
        "positionIncrementGap":"100",
        "analyzer":{
          "charFilters":[{
              "class":"solr.PatternReplaceCharFilterFactory",
              "pattern":"([a-zA-Z])\\\\1+",
              "replacement":"1.8.0_144"}],
          "tokenizer":{
            "class":"solr.WhitespaceTokenizerFactory"},
          "filters":[{
              "class":"solr.WordDelimiterFilterFactory",
              "preserveOriginal":"0"}]}},{code}

 # I was thinking I could possibly trick the overlay config stuff too (but haven't managed to do it yet).
 # I was thinking probably there's ways of using schema or config api to cause an error due to the interpreted value and see that value in the error message in the admin ui log page (haven't managed it yet)

> Unify RedactionUtils and metrics hiddenSysProps settings
> --------------------------------------------------------
>
>                 Key: SOLR-12976
>                 URL: https://issues.apache.org/jira/browse/SOLR-12976
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public)
>          Components: security
>            Reporter: Jan Høydahl
>            Priority: Major
>
> System properties can contain sensitive data, and they are easily available from the Admin UI (/admin/info/system) and also from the Metrics API (/admin/metrics).
> By default the {{/admin/info/system}} redacts any sys prop with a key containing *password*. This can be configured with sysprop {{-Dsolr.redaction.system.pattern=<regex>}}
> The metrics API by default hides these sysprops from the API output:
> {code:java}
>     "javax.net.ssl.keyStorePassword",
>     "javax.net.ssl.trustStorePassword",
>     "basicauth",
>     "zkDigestPassword",
>     "zkDigestReadonlyPassword"
> {code}
> You can redefine these by adding a section to {{solr.xml}}: ([https://lucene.apache.org/solr/guide/7_5/metrics-reporting.html#the-metrics-hiddensysprops-element])
> {code:xml}
> <metrics>
>  <hiddenSysProps>
>    <str>foo</str>
>    <str>bar</str>
>    <str>baz</str>
>  </hiddenSysProps>
> </metrics>{code}
> h2. Unifying the two
> It is not very user firiendly to have two different systems for redacting system properties and two sets of defaults. This goals of this issue are
>  * Keep only one set of defaults
>  * Both metrics and system info handler will use the same source
>  * It should be possible to change and persist the list without a full cluster restart, preferably though some API
> Note that the {{solr.redaction.system.pattern}} property is not documented in the ref guide, so this Jira should also fix documentation!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]