lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Gerlowski <gerlowsk...@gmail.com>
Subject Re: alias read access impossible for anyone other than admin?
Date Tue, 04 Jun 2019 12:07:04 GMT
Hi Sotiris,

First off, forget what I said earlier about the "all" permission.
What I said is mostly correct, but I had forgotten about some of the
other behavior here that complicates things some.

I replicated the behavior you're seeing and spent a bit of time
tracing things through on the Solr side.  I'll walk through it below
in more detail, but ultimately what I think you're running into is
that aliases are resolved _before_ authorization is done.  The only
way to write permissions affecting an alias is to write permissions
that affect the underlying collections.  The way I'm reading the authz
code, a permission like {"collection": "sCollAlias", "path":
"/select/*", "role": "readSCollAlias"} (taken from your first email),
will never have any effect because Solr treats that incoming request
as being for collection "sColl" (I'm just guessing at this name) by
the point authz gets triggered.

> Could someone please ELI5 going through the rules one by one?

RBAP's process of authorizing requests is complicated, but it might
help to think of it happening in 2 distinct steps:

1. Find the first rule (if any) that matches the incoming request.  A
rule matches if the "collection", "path", "method", and "params"
properties all match values in the incoming request.
2. Looks at the "role" for the selected permission.  Allow the request
if the user making the request has this role.  Otherwise deny the
request.

The second half of this process is pretty straightforward.  The first
half (determining which permission rule governs the request) is the
complicated bit that causes most of the confusion.  So in debugging
RBAP, the real question is: how are permissions ordered, and how does
Solr determine which one matches an incoming request?

1. First, Solr figures out which collections are involved in a
request.  Solr looks at the path param (e.g. /solr/foo/select), the
"collection" query-param (e.g.
/collections?action=CLUSTERSTATUS&collection=foo), and resolves any
aliases (e.g. fooAlias -> fooCollection).  It gets the collections
referenced in all these places and puts them together in a list.
2. Solr begins looking for rules that match the incoming request.  A
permission is considered a match if the "collection", "path",
"method", and "params" properties (when defined) all match values on
the incoming request.  security.json shows the permissions in a flat
list, but this isn't the order they're tested in.  Instead, the
permissions are tested in the following order:
2a. Permissions with both "collection" and "path" present and matching
the incoming request
2b. Permissions with "collection" matching, but no path specified
2c. Permissions with no "collection" specified (or the wildcard values
specified) and a "path" matching the incoming request
2d. Permissions agnostic of both "collection" and "path"
3. Within each of the sub-steps above, permissions are tested in the
order they appear in security.json.
4. When testing each individual permission, Solr either looks at the
remaining properties ("method", "params").  If those check out, we've
got a winner.  This is the only permission that will matter for this
request.

So that's the logic in how the rules are processed.  Let's walk
through your originally posted security.json and see how this works
out in practice for a request from "user".  I'm assuming that
sCollAlias is an alias that references the single collection "Coll".
Imagine a request from "user" for
http://<host>:8983/solr/sCollAlias/select?q=*:*

1. Solr looks at the request and realizes that sCollAlias really
points to Coll.  It puts "Coll" in its list of referenced-collections.
2. Solr looks for permissions with a "collection" value of "Coll" and
a path value of "/select".  There is one: {name:readColl,
collection:Coll, path:/select, role:readColl}
3. Looking at that permission further, Solr makes sure the "method"
and "params" properties match the request.  Since the properties
aren't present, they're treated as wildcards and implicitly match.
4. So we've found a matching permission, now Solr checks whether
"user" has the correct role.  The permission says that this request
can only be made by those with the role "readColl".  But "user" only
has the role "readSCollAlias".  So the request is denied.

Hope that example helps.  Let me know if you have any more questions.

Best,

Jason

On Mon, Jun 3, 2019 at 2:06 PM Sotiris Fragkiskos <sfranky@gmail.com> wrote:
>
> it's 7.2.1. Thanks!
>
> On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski <gerlowskija@gmail.com>
> wrote:
>
> > Hi Sotiris,
> >
> > What version of Solr are you running?  The behavior has changed some
> > over time, both intentionally and due to bugs that have come and gone
> > over time.  I (or someone else) can explain things and offer you
> > better help once we know your Solr version.
> >
> > Jason
> >
> > On Mon, Jun 3, 2019 at 12:13 PM Sotiris Fragkiskos <sfranky@gmail.com>
> > wrote:
> > >
> > > Hi again,
> > >
> > > I moved the "all" permission to the bottom as suggested, but it still
> > > doesn't work. Actually, i tried all possible combinations that I could
> > > think of, but I just can't get it to work.
> > > Could there be something else that I'm doing wrong? I'm a complete
> > newbie,
> > > so pretty much anything is a possibility at this point :(
> > > Could it be because I use getfile/putfile commands to update the
> > > security.json file? (it seems to be working, i.e. what i put with putfile
> > > is later retrieved successfully with getfile)
> > > Could there be some system update/refresh mechanism that I'm not aware of
> > > and is currently not taking place?
> > > Could someone please ELI5 going through the rules one by one? I can't
> > > exactly understand the "narrative" that's going on,
> > >
> > > My security.json file's "authorization"  at this point looks like the
> > > snippet below, and almost nothing is working (except admin, and userC
> > who,
> > > for some weird reason, can access  readCollC55b , which is tied to a role
> > > that the userC is NOT tied to..
> > > I'm completely lost.... any pointers, anyone?
> > > Mind you, i'm testing whether it works either directly in the browser by
> > > prepending a "username:password@" to the URL or from the cmdline with a
> > > curl command like so:
> > > *curl http://<user:pass>@IP/solr/collName/select?q=field:value*
> > >
> > > Many thanks!
> > > Sotiri
> > >
> > > "authorization":{
> > >     "class":"solr.RuleBasedAuthorizationPlugin",
> > >     "permissions":[
> > >       {
> > >         "name":"readCollA",
> > >         "collection":"CollA",
> > >         "path":"/select/*",
> > >         "role":"readCollA",
> > >         "index":1},
> > >       {
> > >         "name":"readCollB",
> > >         "collection":"CollB",
> > >         "path":"/select/*",
> > >         "role":"readCollB",
> > >         "index":2},
> > >       {
> > >         "name":"readCollC55b",
> > >         "collection":"CollC55b",
> > >         "path":"/select/*",
> > >         "role":"readCollC55b",
> > >         "index":3},
> > >       {
> > >         "name":"readCollCProduction",
> > >         "collection":"CollCProd",
> > >         "path":"/select/*",
> > >         "role":"readCollCProduction",
> > >         "index":4},
> > >       {
> > >         "name":"all",
> > >         "role":"admin",
> > >         "index":5}],
> > >     "user-role":{
> > >       "admin":[
> > >         "admin",
> > >         "readCollB",
> > >         "readCollA",
> > >         "readCollC55b",
> > >         "readCollCProduction"],
> > >       "userA":["readCollC55b"],
> > >       "userB":["readCollC55b"],
> > >       "userC":["readCollCProduction"],
> > >       "userD":[
> > >         "readCollCProduction",
> > >         "readCollC55b",
> > >         "readCollB",
> > >         "readCollA"]},
> > >
> > >
> > >
> > > On Fri, May 31, 2019 at 9:07 PM Sotiris Fragkiskos <sfranky@gmail.com>
> > > wrote:
> > >
> > > > Terribly sorry about the duplicate post. It was just when i had first
> > > > subscribed, i mustn't have verified my subscription because i never
> > > > received any posts. I could also not find my post in the mailing list
> > > > archive, so I thought it never arrived. It was only today that I tried
> > > > subscribing again (+verifying) that I started receiving emails.
> > > > Thanks for your explanation, I had read this in the manual but it
> > didn't
> > > > make much sense to me. I intepreted my order as: "first rule, the
> > request
> > > > is not from an admin so fail, check the next rule, it's from role
> > readColl
> > > > trying to access Coll, go ahead"
> > > > I will try it as soon as I can. Thanks very much.
> > > > I'm currently using 7.2.
> > > >
> > > > On Fri, May 31, 2019 at 8:27 PM Jason Gerlowski <gerlowskija@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Hi Sotiris,
> > > >>
> > > >> Is this your second time asking this question here, or is there a
> > > >> subtle difference I'm missing?  You asked a very similar question
a
> > > >> week or so ago, and I replied with a few suggestions for changing
your
> > > >> security.json and with a few questions.  In case you missed it for
> > > >> whatever reason, I'll include my original response below:
> > > >>
> > > >> -----
> > > >>
> > > >> Hi Sotiris,
> > > >>
> > > >> First, what version of Solr are you running?  We've made some fixes
> > > >> recently (esp. SOLR-13355) to RBAP, and they might affect the behavior
> > > >> you're seeing or any fixes we can recommend.
> > > >>
> > > >> Second, the order of permissions in security.json has a huge effect
on
> > > >> how .  Solr always uses the first permission rule that matches a given
> > > >> API...later rules are ignored if a match is found in earlier ones.
> > > >> The first rule in your permissions block ({"name": "all", "role":
> > > >> "admin"}) will match all APIs and will only allow requests through
if
> > > >> the requesting user has the "admin" role.  So "user" being unable
to
> > > >> query an alias makes sense.  Usually "all" and other catchall
> > > >> permissions are best used at the very bottom of your permissions list.
> > > >> That way the catchall is the last rule to be checked, giving other
> > > >> rules a chance to match first.
> > > >>
> > > >> Hope that helps.
> > > >>
> > > >> On Fri, May 31, 2019 at 9:34 AM Sotiris Fragkiskos <sfranky@gmail.com
> > >
> > > >> wrote:
> > > >> >
> > > >> > Hi everyone!
> > > >> > I've been trying unsuccessfully to read an alias to a collection
> > with a
> > > >> > curl command.
> > > >> > The command only works when I put in the admin credentials,
> > although the
> > > >> > user I want access for also has the required role for accessing.
> > > >> > Is this perhaps built-in, or should anyone be able to access
an
> > alias
> > > >> from
> > > >> > the API?
> > > >> >
> > > >> > The command I'm using is:
> > > >> > curl http://<user>:<pass>@<solrhostname>/solr
> > > >> > /<AliasName>/select?q=<field>:<value>
> > > >> > This fails for the user but succeeds for the admin
> > > >> >
> > > >> > My minimum working example of security.json follows.
> > > >> > Many thanks!
> > > >> >
> > > >> > {
> > > >> >   "authentication":{
> > > >> >     "blockUnknown":true,
> > > >> >     "class":"solr.BasicAuthPlugin",
> > > >> >     "credentials":{
> > > >> >       "admin":"blahblahblah",
> > > >> >       "user":"blahblah"},
> > > >> >     "":{"v":13}},
> > > >> >   "authorization":{
> > > >> >     "class":"solr.RuleBasedAuthorizationPlugin",
> > > >> >     "permissions":[
> > > >> >       {
> > > >> >         "name":"all",
> > > >> >         "role":"admin",
> > > >> >         "index":1},
> > > >> >       {
> > > >> >         "name":"readColl",
> > > >> >         "collection":"Coll",
> > > >> >         "path":"/select/*",
> > > >> >         "role":"readColl",
> > > >> >         "index":2},
> > > >> >       {
> > > >> >         "name":"readSCollAlias",
> > > >> >         "collection":"sCollAlias",
> > > >> >         "path":"/select/*",
> > > >> >         "role":"readSCollAlias",
> > > >> >         "index":3}],
> > > >> >     "user-role":{
> > > >> >       "admin":[
> > > >> >         "admin",
> > > >> >         "readSCollAlias"],
> > > >> >       "user":["readSCollAlias"]},
> > > >> >     "":{"v":21}}}
> > > >>
> > > >
> >

Mime
View raw message