Solr
  1. Solr
  2. SOLR-7125

Allow clients to upload/download configs via CloudSolrClient

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1
    • Component/s: None
    • Labels:
      None

      Description

      Adding new configs to ZK is still something of a pain point. We should add some helper methods to CloudSolrClient that make this easier.

      1. SOLR-7125.patch
        62 kB
        Alan Woodward
      2. SOLR-7125.patch
        41 kB
        Alan Woodward

        Issue Links

          Activity

          Hide
          Alan Woodward added a comment -

          Patch. I've refactored the ZkController.upload/download methods into a new ZkConfigManager object, which is exposed on ZkStateReader. I also took the opportunity to update them to use NIO2. There are a few more cleanups in ZkController that could be done here, but I'd like to keep that for a follow-up issue.

          Show
          Alan Woodward added a comment - Patch. I've refactored the ZkController.upload/download methods into a new ZkConfigManager object, which is exposed on ZkStateReader. I also took the opportunity to update them to use NIO2. There are a few more cleanups in ZkController that could be done here, but I'd like to keep that for a follow-up issue.
          Hide
          Shawn Heisey added a comment -

          I like it. +1. Config deleting should be there too, as I just described in SOLR-7124.

          Show
          Shawn Heisey added a comment - I like it. +1. Config deleting should be there too, as I just described in SOLR-7124 .
          Hide
          Shawn Heisey added a comment -

          If the back-end code in the config manager is not yet ready, adding it to SolrJ could be done later.

          Show
          Shawn Heisey added a comment - If the back-end code in the config manager is not yet ready, adding it to SolrJ could be done later.
          Hide
          Mark Miller added a comment -

          We have to consider security here just like the other pass config over http right?

          Can a user send in an XSLT file to try and escalate from Solr client access to full machine access?

          Show
          Mark Miller added a comment - We have to consider security here just like the other pass config over http right? Can a user send in an XSLT file to try and escalate from Solr client access to full machine access?
          Hide
          Alan Woodward added a comment -

          Deleting I think can wait for a bit, as it's more complicated (you'd probably have to involve the Overseer to ensure that you're not creating a collection with that config at the same time).

          This is only on CloudSolrClient, not over HTTP. If a black hat has access to your zookeeper there's not a lot we can do to help you

          Show
          Alan Woodward added a comment - Deleting I think can wait for a bit, as it's more complicated (you'd probably have to involve the Overseer to ensure that you're not creating a collection with that config at the same time). This is only on CloudSolrClient, not over HTTP. If a black hat has access to your zookeeper there's not a lot we can do to help you
          Hide
          Hoss Man added a comment - - edited

          Alan: i don't know all the details, but SOLR-6915 is pretty much on point here in terms of letting solr read/write what it needs to in ZK, while some subset of users can modify configs, while other clients/users may only have read access to ZK.

          just because someone can create CloudSolrClient instance and get the list of active nodes from ZK doesn't mean they can/should be allowed full write access to ZK.


          EDIT: to clarify my point: i'm not saying we shouldn't support this in CloudSolrClient, i'm saying if we support it, we need to keep the security conious use case in mind and ensure we have a good story/docs for folks who care about things like SOLR-6915 ... maybe it "just works" because the ZK credentials used when constructing the CloudSolrClient instance are prevented from writing to those config nodes in these secure cases, and they returne a good error message ... but we should think about that and test it.

          Show
          Hoss Man added a comment - - edited Alan: i don't know all the details, but SOLR-6915 is pretty much on point here in terms of letting solr read/write what it needs to in ZK, while some subset of users can modify configs, while other clients/users may only have read access to ZK. just because someone can create CloudSolrClient instance and get the list of active nodes from ZK doesn't mean they can/should be allowed full write access to ZK. EDIT: to clarify my point: i'm not saying we shouldn't support this in CloudSolrClient, i'm saying if we support it, we need to keep the security conious use case in mind and ensure we have a good story/docs for folks who care about things like SOLR-6915 ... maybe it "just works" because the ZK credentials used when constructing the CloudSolrClient instance are prevented from writing to those config nodes in these secure cases, and they returne a good error message ... but we should think about that and test it.
          Hide
          Mark Miller added a comment -

          This is only on CloudSolrClient, not over HTTP.

          But CloudSolrClient does go over http doesnt it?

          If a black hat has access to your zookeeper there's not a lot we can do to help you

          We have security controls for zookeeper now - you can have a CloudSolrClient, you can have limited Zk perms for a Solr space (read only even for CloudSolrClient). That's all fine. We can't allow a guy in that situation to be able to root the Solr instance machine from another machine. That is a large security hole.

          Show
          Mark Miller added a comment - This is only on CloudSolrClient, not over HTTP. But CloudSolrClient does go over http doesnt it? If a black hat has access to your zookeeper there's not a lot we can do to help you We have security controls for zookeeper now - you can have a CloudSolrClient, you can have limited Zk perms for a Solr space (read only even for CloudSolrClient). That's all fine. We can't allow a guy in that situation to be able to root the Solr instance machine from another machine. That is a large security hole.
          Hide
          Mark Miller added a comment - - edited

          I'm not saying this is an impossible feature by the way. But the security issue has to be very well considered, documented, prevented, tackled etc, etc.

          We keep spawning issues to upload config, but until someone tackles the root security problem, none of them can go anywhere

          Show
          Mark Miller added a comment - - edited I'm not saying this is an impossible feature by the way. But the security issue has to be very well considered, documented, prevented, tackled etc, etc. We keep spawning issues to upload config, but until someone tackles the root security problem, none of them can go anywhere
          Hide
          Alan Woodward added a comment -

          But CloudSolrClient does go over http doesnt it?

          For normal requests, yes, but it also has a ZkStateReader, which is what this code uses. I'll add a test for ZkCredentials, etc.

          Show
          Alan Woodward added a comment - But CloudSolrClient does go over http doesnt it? For normal requests, yes, but it also has a ZkStateReader, which is what this code uses. I'll add a test for ZkCredentials, etc.
          Hide
          Alan Woodward added a comment -

          And if ZkCredentials doesn't work in this case, then it's an existing security hole, which needs fixing, as anybody can create a CloudSolrClient and pull it's SolrZkClient/ZkStateReader...

          Show
          Alan Woodward added a comment - And if ZkCredentials doesn't work in this case, then it's an existing security hole, which needs fixing, as anybody can create a CloudSolrClient and pull it's SolrZkClient/ZkStateReader...
          Hide
          Mark Miller added a comment -

          then it's an existing security hole, which needs fixing, as anybody can create a CloudSolrClient and pull it's SolrZkClient/ZkStateReader.

          Yeah, it's a tricky situation. Part of why securing ZK is so important I suppose - we should add a bit about that to the ref guide.

          My worry is the bank that does secure ZK though, not the one that doesn't. If you have it so that out of the box CloudSolrServer can upload config that can end up as executable code, that is a dangerous situation.

          I suppose this issue highlights something we have to consider rather than exposes it.

          Show
          Mark Miller added a comment - then it's an existing security hole, which needs fixing, as anybody can create a CloudSolrClient and pull it's SolrZkClient/ZkStateReader. Yeah, it's a tricky situation. Part of why securing ZK is so important I suppose - we should add a bit about that to the ref guide. My worry is the bank that does secure ZK though, not the one that doesn't. If you have it so that out of the box CloudSolrServer can upload config that can end up as executable code, that is a dangerous situation. I suppose this issue highlights something we have to consider rather than exposes it.
          Hide
          Mark Miller added a comment -

          So I've thought on this a bit. I guess this is best addressed by some work in the ref guide on zk security - we recommend that if you are securing zk for reasonable shared access that you need to lock down config and can't use features such as this without an exploit risk.

          In the longer term, I wonder if we can just stop allowing xslt execution...or at least by default like we do binary uploads.

          Show
          Mark Miller added a comment - So I've thought on this a bit. I guess this is best addressed by some work in the ref guide on zk security - we recommend that if you are securing zk for reasonable shared access that you need to lock down config and can't use features such as this without an exploit risk. In the longer term, I wonder if we can just stop allowing xslt execution...or at least by default like we do binary uploads.
          Hide
          Alan Woodward added a comment -

          Patch with added security test. Turns out that SolrZkClient does indeed handle the security aspects here, although it's a bit of a pain setting it up properly.

          The new test creates a ZK that has three levels of access: writeable, readable, and no creds. It then tests that if you create your config node with the writeable access that a client with read-only access can't upload new configs, and that a client with no auth whatsoever can't even list configs.

          Show
          Alan Woodward added a comment - Patch with added security test. Turns out that SolrZkClient does indeed handle the security aspects here, although it's a bit of a pain setting it up properly. The new test creates a ZK that has three levels of access: writeable, readable, and no creds. It then tests that if you create your config node with the writeable access that a client with read-only access can't upload new configs, and that a client with no auth whatsoever can't even list configs.
          Hide
          Mark Miller added a comment -

          Great to have a new test!

          I'm sure it will work - my main concern is the team securing things for shared use. Say they have employees with different levels of access, they turn on ZK security, they see they can upload config with CloudSolrServer or whatever and so they allow the config node to be written to, what's the harm, the client can only edit and upload config, and now they have opened up a remote exploit hole. Unfortunately, until we close that hole, I think the best we can do is doc the problem a lot in the ref guide.

          Show
          Mark Miller added a comment - Great to have a new test! I'm sure it will work - my main concern is the team securing things for shared use. Say they have employees with different levels of access, they turn on ZK security, they see they can upload config with CloudSolrServer or whatever and so they allow the config node to be written to, what's the harm, the client can only edit and upload config, and now they have opened up a remote exploit hole. Unfortunately, until we close that hole, I think the best we can do is doc the problem a lot in the ref guide.
          Hide
          Alan Woodward added a comment -

          Should I commit then, or do we need to think more about the docs first? I don't think this is exposing anything that wasn't already exposed...

          Show
          Alan Woodward added a comment - Should I commit then, or do we need to think more about the docs first? I don't think this is exposing anything that wasn't already exposed...
          Hide
          Mark Miller added a comment -

          Yeah, if it's ready, it's fine to commit. I'll work on the docs.

          Show
          Mark Miller added a comment - Yeah, if it's ready, it's fine to commit. I'll work on the docs.
          Hide
          Mark Miller added a comment - - edited

          We might want to mention in the javadoc around those methods that allowing upload of config to zk is a possible exploit hole - it's just a nice place to possibly flag this for users - in that case it might be nice to link to the doc.

          Show
          Mark Miller added a comment - - edited We might want to mention in the javadoc around those methods that allowing upload of config to zk is a possible exploit hole - it's just a nice place to possibly flag this for users - in that case it might be nice to link to the doc.
          Hide
          ASF subversion and git services added a comment -

          Commit 1660919 from Alan Woodward in branch 'dev/trunk'
          [ https://svn.apache.org/r1660919 ]

          SOLR-7125: Allow upload and download of configs via CloudSolrClient

          Show
          ASF subversion and git services added a comment - Commit 1660919 from Alan Woodward in branch 'dev/trunk' [ https://svn.apache.org/r1660919 ] SOLR-7125 : Allow upload and download of configs via CloudSolrClient
          Hide
          ASF subversion and git services added a comment -

          Commit 1660922 from Alan Woodward in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1660922 ]

          SOLR-7125: Allow upload and download of configs via CloudSolrClient

          Show
          ASF subversion and git services added a comment - Commit 1660922 from Alan Woodward in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1660922 ] SOLR-7125 : Allow upload and download of configs via CloudSolrClient
          Hide
          Alan Woodward added a comment -

          Thanks Mark, I've added a note to the Javadoc as well.

          Show
          Alan Woodward added a comment - Thanks Mark, I've added a note to the Javadoc as well.
          Hide
          ASF subversion and git services added a comment -

          Commit 1660925 from Alan Woodward in branch 'dev/trunk'
          [ https://svn.apache.org/r1660925 ]

          SOLR-7125: Add note to javadocs

          Show
          ASF subversion and git services added a comment - Commit 1660925 from Alan Woodward in branch 'dev/trunk' [ https://svn.apache.org/r1660925 ] SOLR-7125 : Add note to javadocs
          Hide
          ASF subversion and git services added a comment -

          Commit 1660926 from Alan Woodward in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1660926 ]

          SOLR-7125: Add note to javadocs

          Show
          ASF subversion and git services added a comment - Commit 1660926 from Alan Woodward in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1660926 ] SOLR-7125 : Add note to javadocs
          Hide
          Shawn Heisey added a comment -

          I was trying to think of a way other than ZK security to have a default config that would disable this functionality, but I don't think there's any way to do it that would still allow zkcli to work.

          If we don't already have a full section in the ref guide about security, perhaps we need one.

          Show
          Shawn Heisey added a comment - I was trying to think of a way other than ZK security to have a default config that would disable this functionality, but I don't think there's any way to do it that would still allow zkcli to work. If we don't already have a full section in the ref guide about security, perhaps we need one.
          Hide
          Mark Miller added a comment -

          I was trying to think of a way other than ZK security to have a default config that would disable this functionality, but I don't think there's any way to do it that would still allow zkcli to work.

          I think you have two options for real security at this point:

          • Lock down access to ZK service, people that have access to ZK may be able to exploit Solr. Standard situation.
          • Allow various clients to access ZK service and use ZK auth controls, most can't update ZK config, only those that can (if any) may be able to exploit Solr.

          If we don't already have a full section in the ref guide about security, perhaps we need one.

          I think we do need one - we have crept further and further into it, and now we are pretty deep.

          Show
          Mark Miller added a comment - I was trying to think of a way other than ZK security to have a default config that would disable this functionality, but I don't think there's any way to do it that would still allow zkcli to work. I think you have two options for real security at this point: Lock down access to ZK service, people that have access to ZK may be able to exploit Solr. Standard situation. Allow various clients to access ZK service and use ZK auth controls, most can't update ZK config, only those that can (if any) may be able to exploit Solr. If we don't already have a full section in the ref guide about security, perhaps we need one. I think we do need one - we have crept further and further into it, and now we are pretty deep.
          Hide
          ASF subversion and git services added a comment -

          Commit 1661506 from Alan Woodward in branch 'dev/trunk'
          [ https://svn.apache.org/r1661506 ]

          SOLR-7125: Don't upload dotfiles

          Show
          ASF subversion and git services added a comment - Commit 1661506 from Alan Woodward in branch 'dev/trunk' [ https://svn.apache.org/r1661506 ] SOLR-7125 : Don't upload dotfiles
          Hide
          ASF subversion and git services added a comment -

          Commit 1661507 from Alan Woodward in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1661507 ]

          SOLR-7125: Don't upload dotfiles

          Show
          ASF subversion and git services added a comment - Commit 1661507 from Alan Woodward in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1661507 ] SOLR-7125 : Don't upload dotfiles
          Hide
          ASF subversion and git services added a comment -

          Commit 1665254 from Alan Woodward in branch 'dev/trunk'
          [ https://svn.apache.org/r1665254 ]

          SOLR-7125: Call process() before trying to upload/download configs

          Show
          ASF subversion and git services added a comment - Commit 1665254 from Alan Woodward in branch 'dev/trunk' [ https://svn.apache.org/r1665254 ] SOLR-7125 : Call process() before trying to upload/download configs
          Hide
          ASF subversion and git services added a comment -

          Commit 1665255 from Alan Woodward in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1665255 ]

          SOLR-7125: Call process() before trying to upload/download configs

          Show
          ASF subversion and git services added a comment - Commit 1665255 from Alan Woodward in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1665255 ] SOLR-7125 : Call process() before trying to upload/download configs
          Hide
          Noble Paul added a comment -

          does this allow upload of config also ?

          Show
          Noble Paul added a comment - does this allow upload of config also ?
          Hide
          Alan Woodward added a comment -

          This lets you add a config (schema and solrconfig, etc) from your filesystem to ZK via a CloudSolrClient.

          Show
          Alan Woodward added a comment - This lets you add a config (schema and solrconfig, etc) from your filesystem to ZK via a CloudSolrClient.
          Hide
          Timothy Potter added a comment -

          Bulk close after 5.1 release

          Show
          Timothy Potter added a comment - Bulk close after 5.1 release

            People

            • Assignee:
              Alan Woodward
              Reporter:
              Alan Woodward
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development