[
https://issues.apache.org/jira/browse/SOLR-18446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118228#comment-18118228
]
David Smiley commented on SOLR-18446:
-------------------------------------
Thanks Jan. That was a catalyst for me to look closer to understand the
current issue more deeply. I became very suspicious of the patch after seeing
what it was doing and I now fundamentally disagree with it. The root issue of
vulnerability is that authorization targets a different collection than the one
that executes: when the URL path names a core, {{HttpSolrCall}} authorizes
against the {{collection}} param while the handler runs on the core's
collection. {{distrib=false}} is only one way to get there. From reading the
code, updates look affected with no {{distrib}} at all, because
{{DistributedZkUpdateProcessor}} writes to the core's collection regardless of
the param. So {{/solr/<coreOfA>/update?collection=B}} would be authorized
against B but write to A. _(I haven't verified this with a test yet.)_
Authorizing against both doesn't work either, since RBAP lets the first
collection with a matching rule decide.
Counter-Proposal: *authorize against the collection of the core the request is
dispatched to, and don't use the {{collection}} param for authorization at
all.* Routing and fan-out stay as they are. Anything sent to other collections
goes out as sub-requests that carry the user's principal via PKI, and each
receiving node authorizes against its own core, so a denial there fails the
request. That makes {{distrib}} irrelevant and closes the whole class. The one
visible side effect: {{/solr/A/select?collection=B}} now also needs permission
on A. I'm working on a patch along these lines, reusing the existing end-to-end
test and adding an update case.
[~gus] I expect you will be a big fan of this as I distinctly remember your
recommendation on the security list about resolving authz at the place of
execution instead of trying to predict up-front the target collections
involved. Big +1 to that.
🤖 Drafted with Claude Code
> Remove "collection" param routing support in HttpSolrCall
> ---------------------------------------------------------
>
> Key: SOLR-18446
> URL: https://issues.apache.org/jira/browse/SOLR-18446
> Project: Solr
> Issue Type: Improvement
> Components: Server
> Reporter: David Smiley
> Priority: Blocker
> Fix For: main(11.0)
>
>
> The URL path alone should govern which collection receives a
> collection-scoped request. Node level APIs (e.g. admin) don't count here.Â
> Consequently, the "collection" parameter should be removed or altered in
> semantics from the present day.Â
> It'd be harmless if the collection param were to assist in disambiguating a
> core name in the path, if we want that, as that prevents a 404.
> It'd be harmless if the collection param disambiguated multiple possibilities
> if the path implied more than one (i.e. was an alias to multiple collections
> or was comma delimited).
> It's acknowledged and out-of-scope that there are parameters like "shards"
> affecting how a handler (e.g. SearchHandler) dispatch distributed work. The
> scope of the current ticket is basically HttpSolrCall resolving to a "core"
> locally or remotely.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
