[
https://issues.apache.org/jira/browse/SOLR-16907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17750386#comment-17750386
]
Uwe Schindler commented on SOLR-16907:
--------------------------------------
bq. I think that's what's happening here. In 8.x "autoscaling-write" was a
predefined permission that only applied to specific request handlers. But in
9.x that same rule in security.json is being interpreted as a custom permission
that is intended to match requests for any collection, path, HTTP method, etc.
That was my first idea. Maybe it should keep an internal entry about all the
old exsiting predefined permissions. When they are encountered it should log a
warning (asking users to remove them).
On the other hand: Any custom permission must be defined somewhere.
"autoscaling-write" is not defined anywhere, so shouldn't it throw error?
bq. But I agree this is definitely a logging failure. IMO a more effective
place to log would be when we load in security.json and notice the sketchy
permissions.
Either like this, or log them by default: If it gets too noisy for user XY you
can always silence those logs by reconfigure them to "error". That's easy with
admin UI or by adding a line to log4j.xml.
bq. We can't print warnings on any "unknown" permissions, since we're
apparently intent on supporting custom permissions going forward. But it'd be
pretty easy to warn about permissions whose names are in a set of "old perms
that have been removed from Solr". Or we could warn about "match all"
permissions that don't specify any criteria.
See above, I have the same idea. Just check the old hardcoded permissions in
8.x source tree and preserve them as "deprecated" ones in some HashSet or
whatever.
> 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
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Authentication, Authorization
> Affects Versions: 9.0, 9.1, 9.2, 9.3
> Reporter: Uwe Schindler
> Priority: Major
> Attachments: security.json
>
>
> 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
