Hey Craig,
I think this will be tricky to do with the current Rule-Based
Authorization support. As you pointed out in your initial post -
there are lots of ways to delete documents. The Rule-Based Auth code
doesn't inspect request bodies (AFAIK), so it's going to have trouble
differentiating between traditional "/update" requests with
method=POST that are request-body driven.
But to zoom out a bit, does it really make sense to lock down deletes,
but not updates more broadly? After all, "updates" can remove and add
fields. Users might submit an update that strips everything but "id"
from your documents. In many/most usecases that'd be equally
concerning. Just wondering what your usecase is - if it's generally
applicable this is probably worth a JIRA ticket.
Best,
Jason
On Thu, Nov 19, 2020 at 10:34 AM Oakley, Craig (NIH/NLM/NCBI) [C]
<craig.oak...@nih.gov.invalid> wrote:
>
> Having not heard back, I thought I would ask again whether anyone else has
> been able to use security.json to disallow deletes, and/or if anyone has
> examples of using the "method" section in
> lucene.apache.org/solr/guide/8_4/rule-based-authorization-plugin.html
>
> -----Original Message-----
> From: Oakley, Craig (NIH/NLM/NCBI) [C] <craig.oak...@nih.gov.INVALID>
> Sent: Monday, October 26, 2020 6:23 PM
> To: solr-user@lucene.apache.org
> Subject: disallowing delete through security.json
>
> I am interested in disallowing delete through security.json
>
> After seeing the "method" section in
> lucene.apache.org/solr/guide/8_4/rule-based-authorization-plugin.html my
> first attempt was as follows:
>
> {"set-permission":{
> "name":"NO_delete",
> "path":["/update/*","/update"],
> "collection":col_name,
> "role":"NoSuchRole",
> "method":"DELETE",
> "before":4}}
>
> I found, however, that this did not disallow deleted: I could still run
> curl -u ... "http://.../solr/col_name/update?commit=true"; --data
> "<delete><query>id:11</query></delete>"
>
> After further experimentation, I seemed to have success with
> {"set-permission":
> {"name":"NO_delete6",
> "path":"/update/*",
> "collection":"col_name",
> "role":"NoSuchRole",
> "method":["REGEX:(?i)DELETE"],
> "before":4}}
>
> My initial impression was that this did what I wanted; but now I find that
> this disallows *any* updates to this collection (which had previously been
> allowed). Other attempts to tweak this strategy, such as granting permissions
> for "/update/*" for methods other than DELETE to a role which is granted to
> the desired user, have not yet been successful.
>
> Does anyone have an example of security.json disallowing a delete while still
> allowing an update?
>
> Thanks
