[
https://issues.apache.org/jira/browse/SOLR-16907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17783685#comment-17783685
]
ASF subversion and git services commented on SOLR-16907:
--------------------------------------------------------
Commit 2062d057c003e4113b09b8e6aab49caa134b4a7c in solr's branch
refs/heads/main from Jan Høydahl
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=2062d057c00 ]
SOLR-16907: Fail when parsing an invalid custom permission definition from
security.json (#2040)
> Strange behaviour after upgrade to 9.x when security json has no longer
> existing permission
> -------------------------------------------------------------------------------------------
>
> Key: SOLR-16907
> URL: https://issues.apache.org/jira/browse/SOLR-16907
> Project: Solr
> Issue Type: Bug
> Components: Authentication, Authorization
> Affects Versions: 9.0, 9.1, 9.2, 9.3, 9.4
> Reporter: Uwe Schindler
> Assignee: Jan Høydahl
> Priority: Major
> Attachments: security.json
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> I had a very strange behaviour of Authorization after migrating a standalone
> solr instance to Solr 9 keeping the existing security.json file.
>
> To reproduce, place the attached [^security.json] in the solr.home (it has
> default password "SolrRocks"). The only change I did was adding
> {{"blockUnknown":false}}, because the whole idea of the file is just to
> prevent people doing some changes to configuration, but all
> queries/select/.... on cores/collections should work without authentication
> (basically to prevent the developers from accessing admin UI and change
> something).
> After applying this config, all requests to any core were denied with
> "Authentication failed, Response code: 401". This message does not come from
> the "BasicAuthenticationProvider" (hint: if you enable "blockUnknown", it
> fails earlier and print as error message: "require authentication" coming
> from BasicAuthenticationProvider). So the problem was *not* caused by the
> setting "blockUnknown=false" ignored.
> It took me a long time to actually find the reason and without enabling debug
> logging and going through all settings I found the issue. This is totally
> unexpected and should be fixed as no warning or reason is printed to default
> log.
> {noformat}
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler
> scope null||/solr/techproducts/select @
> o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe
> Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp}
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.h.ContextHandler
> context=/solr||/techproducts/select @
> o.e.j.w.WebAppContext@49a64d82{solr-jetty-context.xml,/solr,file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/,AVAILABLE}{C:\Users\Uwe
> Schindler\Desktop\solr-9.3.0-slim\server/solr-webapp/webapp}
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler
> servlet /solr|/techproducts/select|null|ServletPathMapping{matchValue=,
> pattern=/, servletName=default, mappingMatch=DEFAULT,
> servletPath=/techproducts/select, pathInfo=null} ->
> default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED}
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [] o.e.j.s.ServletHandler
> chain=Chain@47a4b5d5(SolrRequestFilter==org.apache.solr.servlet.SolrDispatchFilter@30d15e4a{inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/solr-webapp/webapp/WEB-INF/web.xml})->ChainEnd@2c16acde(default==org.eclipse.jetty.servlet.DefaultServlet@5c13d641{jsp=null,order=0,inst=true,async=false,src=DESCRIPTOR:file:///C:/Users/Uwe%20Schindler/Desktop/solr-9.3.0-slim/server/etc/webdefault.xml,STARTED})
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) []
> o.a.s.s.SolrDispatchFilter Request to authenticate:
> org.apache.solr.servlet.ServletUtils$1@5726199e, domain: 127.0.0.1, port: 8983
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) []
> o.a.s.s.SolrDispatchFilter User principal: null
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.a.s.s.AuthorizationUtils AuthorizationContext : userPrincipal: [null] type:
> [READ], collections: [], Path: [/select] path : /select params :
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.a.s.s.RuleBasedAuthorizationPluginBase Attempting to authorize request to
> [/select] of type: [READ], associated with collections [[]]
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.a.s.s.RuleBasedAuthorizationPluginBase Authorizing collection-aware
> request, checking perms applicable to all (*) collections
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.a.s.s.RuleBasedAuthorizationPluginBase Found perm [{
> "name":"autoscaling-write",
> "role":"admin",
> "index":5}] to govern resource [/select]
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.a.s.s.RuleBasedAuthorizationPluginBase Governing permission [{
> "name":"autoscaling-write",
> "role":"admin",
> "index":5}] has role, but request principal cannot be identified;
> forbidding access
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.a.s.s.AuthorizationUtils USER_REQUIRED null null
> 2023-07-27 08:48:23.929 DEBUG (qtp1963075870-46) [ x:techproducts]
> o.e.j.s.HttpChannelState sendError HttpChannelState@ca1dc41{s=HANDLING
> rs=BLOCKING os=OPEN is=IDLE awp=false se=false i=true al=0}
> {noformat}
> The reason is that the role map still contains the *outdated* 8.x
> "autoscaling-write" permission and for unknown reason it is selected as
> permission that needs to be enforced for /select queries to the core. I have
> no idea why this happens! This is in my opinion the main issue here. After
> that, the rule based authorization figures out that the principal is null and
> send the 401 response with useless error message (and by default no log entry
> at all!!!!).
> After removing the outdated perm from the security.json, requests to /select
> go through without authentication.
> This problem may affect other people when upgrading Solr, as it is totally
> unexpected that a no longer existing permission is selected to authorize!
> To fix please try to be more helpful:
> - Log warnings when authorization fail, so one must not use DEBUG logging!
> - fix the bug that "autoscaling-write" is selected as permission for any
> request to the core (not only /select is affected, everything).
> - if a permission is unknown (legacy from 8.x), a warning should be printed
> on startup and in the admin UI
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
