From solr-user-return-148213-archive-asf-public=cust-asf.ponee.io@lucene.apache.org Wed Jun 5 09:13:11 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id C5FCF18065D for ; Wed, 5 Jun 2019 11:13:10 +0200 (CEST) Received: (qmail 23008 invoked by uid 500); 5 Jun 2019 09:13:04 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 22319 invoked by uid 99); 5 Jun 2019 09:13:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Jun 2019 09:13:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 9711AC1E01 for ; Wed, 5 Jun 2019 09:13:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.8 X-Spam-Level: ** X-Spam-Status: No, score=2.8 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id BUySiowgMhWP for ; Wed, 5 Jun 2019 09:12:58 +0000 (UTC) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 12F9A5F529 for ; Wed, 5 Jun 2019 09:12:58 +0000 (UTC) Received: by mail-vs1-f52.google.com with SMTP id l125so15220779vsl.13 for ; Wed, 05 Jun 2019 02:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2GjLKgNBtJFZrwwGol03q4LX3jvfSJaHSJgOoNROkAM=; b=O+660Wi4SWD8KkEuMWPbG/xzQ0QV5mF8y557c/5qk41BvkAI/e/k/GvyGHtuRgS2sH 974+R69EZ6OVgfRZICdDxjDUrY/r8yy/gJSxMq/yo+TGT0fWIqNiPJ7CmLb5Qq5tsTFm cLYEc8yyNFyDE6LDRPE99Bd++EWsuMfsYVD8EgQ0Rodcn0KzkjobnkmyLYVNNGzb/3Wn h3tG28ar0s3+Zk4c+xX1/Bi2HJFLGBFcAMBTS1XR6P4ke4R7Sa0ifss5c27IgeY9yjok WQZAP/c5jlBDkCpZ7BxrsTBIv9q+oA/DovJ87R79qsCKiyOed2ZIoSZNSfH7td8SAsqY 2lSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2GjLKgNBtJFZrwwGol03q4LX3jvfSJaHSJgOoNROkAM=; b=IsRfL3tgmpafDO65b04atwnC/142vvnygGMxz+m0ye0MESKXMyAHMeySyDCTiiboqJ ZIKWBW5hCLecOEFhTrtJ0jZQmdqbaWP1Ry5jia8n8aj6iQnXVHwhRcXSIrJRJwaYcX7Y Lk1nYoBe8WX7UAbKDNed3BJEKLu7K7yITXTThcz8pYGkBZPV/hwQS70iaiSA+akFQ9WO V0ZEwb0FEXb82gsieLfv/9jVxK6FDCogKOlOJf2PMQokxv1Q+xOsjOT8ocx4YxadbvSj Hryb6gv85mIhOW/SaN3vnt4hlNqC708deJpkOY0jp/EpqOFIFXAXfpvtmExC17vdbmna LXWQ== X-Gm-Message-State: APjAAAXwm9ezPgOHbFB1z0DnuaAMhy54oLh4FRGqqt6cPxi6WbLwbI6s E4ZiL06Hpsi+h1f/i+JJQ1xEB0zWem8JY+Ch/Yypfw== X-Google-Smtp-Source: APXvYqw46X101V70PLWzXptLM6xwNvzRWr6DOEQo42P3om3MXJh0EFkSJzwHOuxI1OcQwHFdG28/d2+mWHhi2SmhJpM= X-Received: by 2002:a67:b847:: with SMTP id o7mr6136502vsh.5.1559725971022; Wed, 05 Jun 2019 02:12:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Sotiris Fragkiskos Date: Wed, 5 Jun 2019 11:12:14 +0200 Message-ID: Subject: Re: alias read access impossible for anyone other than admin? To: solr-user@lucene.apache.org Content-Type: multipart/alternative; boundary="000000000000732d79058a900098" --000000000000732d79058a900098 Content-Type: text/plain; charset="UTF-8" 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 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://: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 > wrote: > > > > it's 7.2.1. Thanks! > > > > On Mon, Jun 3, 2019 at 6:26 PM Jason Gerlowski > > 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 > > > 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://@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://:@/solr > > > > >> > //select?q=: > > > > >> > 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}}} > > > > >> > > > > > > > > > --000000000000732d79058a900098--