janhoy commented on code in PR #5016:
URL: https://github.com/apache/solr/pull/5016#discussion_r4190125244
##########
solr/solr-ref-guide/modules/upgrade-notes/pages/major-changes-in-solr-11.adoc:
##########
@@ -41,3 +41,11 @@ bin/solr start -Dsolr.node.roles=data:on,overseer:preferred
A node started this way asks the Overseer to re-run its node prioritization,
so a preferred node takes over without waiting for the current Overseer to
restart.
Note that node roles are fixed for the lifetime of a node: unlike `ADDROLE`,
they cannot be changed on a running node.
+
+== Security Changes
+
+=== Core-Scoped Authorization Rules in Standalone Mode
+
+In standalone mode, authorization permissions that set `collection` to a core
name were never applied, so requests to that core were matched only against the
permissions that apply to all collections.
Review Comment:
I'm not sure this warrants a major-change section at all? It's not really a
major feature, it's pretty niche. If we need one, it should be scoped for 10.2,
not 11.0
##########
solr/core/src/java/org/apache/solr/servlet/HttpSolrCall.java:
##########
@@ -219,13 +219,19 @@ public List<String> getCollectionsList() {
/**
* The collection(s) to authorize this request against. In SolrCloud, when a
local core serves the
* request, this is the collection of that core, since that is where the
request executes;
- * requests it sends to other collections are authorized by the receiving
nodes. Otherwise, this
- * is {@link #getCollectionsList()}. Not null.
+ * requests it sends to other collections are authorized by the receiving
nodes. In standalone
+ * mode this is the name of the core serving the request, since there are no
collections.
+ * Otherwise, this is {@link #getCollectionsList()}. Not null.
*/
public List<String> getAuthorizationCollectionsList() {
- if (core == null || !cores.isZooKeeperAware()) {
+ if (core == null) {
return getCollectionsList();
}
+ if (!cores.isZooKeeperAware()) {
+ // Standalone mode has no collections; authorize against the serving
core's name so that
+ // core-scoped authorization rules can match.
+ return List.of(core.getCoreDescriptor().getName());
Review Comment:
What if the user requested results from two different cores using the
`shards` parameter, should not both be subject to authorization?
>
http://localhost:8983/solr/core1/select?q=*:*&shards=localhost:8983/solr/core1,localhost:8983/solr/core2
##########
changelog/unreleased/SOLR-13097.yml:
##########
@@ -0,0 +1,7 @@
+title: Authorization permissions scoped to a core with the collection field
are now enforced in standalone mode, where they were silently ignored
+type: changed
Review Comment:
Either frame this as a `fixed` with title describing what bug was fixed, or
frame it as `added` with title describing the new capability.
The JIRA is labeled as bug. I'm not sure that is accurate, unless our
documentation says that this should work in standalone mode?
Have you checked whether some ref-guide page needs updating, perhaps
mentioning explicitly that the `collection` parameter in security.json can also
take a core name in standalone mode?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
