You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Sotiris Fragkiskos <sf...@gmail.com> on 2019/06/03 16:12:39 UTC
Re: alias read access impossible for anyone other than admin?
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 <sf...@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 <ge...@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 <sf...@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}}}
>>
>
Re: alias read access impossible for anyone other than admin?
Posted by Sotiris Fragkiskos <sf...@gmail.com>.
Hi Json,
Many thanks for this excellent explanation, it's all now clear to me, I've
fixed the problem!
I didn't anticipate that the aliases would be resolved before everything
else..
Thanks again!
Sotiri
On Tue, Jun 4, 2019 at 2:07 PM Jason Gerlowski <ge...@gmail.com>
wrote:
> 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 <sf...@gmail.com>
> wrote:
> >
> > it's 7.2.1. Thanks!
> >
> > On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski <ge...@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 <sf...@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}}}
> > > > >>
> > > > >
> > >
>
Re: alias read access impossible for anyone other than admin?
Posted by Jason Gerlowski <ge...@gmail.com>.
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 <sf...@gmail.com> wrote:
>
> it's 7.2.1. Thanks!
>
> On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski <ge...@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 <sf...@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 <sf...@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}}}
> > > >>
> > > >
> >
Re: alias read access impossible for anyone other than admin?
Posted by Sotiris Fragkiskos <sf...@gmail.com>.
it's 7.2.1. Thanks!
On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski <ge...@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 <sf...@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 <sf...@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}}}
> > >>
> > >
>
Re: alias read access impossible for anyone other than admin?
Posted by Jason Gerlowski <ge...@gmail.com>.
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 <sf...@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 <sf...@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 <ge...@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 <sf...@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}}}
> >>
> >