ACL based on host.

[hecrogu]

Hi!,

I was using your plugin in an older version of elasticsearch (2.1.2). Now I upgrade my elastic's version to 2.3.2 and update your plugin version to 1.9.3, which should be compatible with elastic 2.3.2, but my old configuration of your plugin doesn't works. Is it any change in the way of applied that configuration?

My old configuration was in elasticsearch.yml and contains: ``

# Readonlyrest plugin
readonlyrest:
    # (De)activate plugin
    enable: true

    # HTTP response body in case of forbidden request.
    # If this is null or omitted, the name of the first violated access control rule is returned (useful for debuggi$
    response_if_req_forbidden: Sorry, your request is forbidden

    # Default policy is to forbid everything, let's define a whitelist
    access_control_rules:

    # from these IP addresses, accept any method, any URI, any HTTP body
    - name: full access to internal servers
      type: allow
      hosts: [127.0.0.1, ip1, ip2]

`` But for now i can access from every site.

Thanks for your work.

[sscarduzio]

Just tested, can't reproduce. Are you sure all the indentation is proper? To see if all the configuration and rules are properly discovered, grep for plugin.readonlyrest. You should see something along these lines:

[2016-05-15 17:15:20,959][INFO ][plugin.readonlyrest ] [Bela] Readonly REST plugin was loaded... [2016-05-15 17:15:20,959][INFO ][plugin.readonlyrest ] [Bela] Readonly REST plugin is enabled. Yay, ponies! [2016-05-15 17:15:21,056][INFO ][plugin.readonlyrest.acl ] ADDING readonlyrest Rules Block :: { name: 'host rule', policy: ALLOW}

Also, your case is really strange because if the plugin is enabled and no rule block is matched, the default behaviour is to reject the request. The only thing I can imagine is that the plugin is not at all loaded.

Another scenario would be that for some network related issues, your requests are seen as coming from localhost (proxy? SSH tunnels?). You can inspect the originating address of a requests setting ES in trace mode. I.E.:

[2016-05-15 17:23:12,392][TRACE][plugin.readonlyrest.acl ] checking request:{ action: indices:admin/create, OA:192.168.236.128, indices:[index1], M:PUT, P:/index1, C:, Headers:[]} You can see that this request comes from 192.168.236.128. See what's your test request coming from.

[hecrogu]

Restarting elastic y can see this lines:

[2016-05-16 08:02:43,101][INFO ][plugin.readonlyrest ] [Dust] Readonly REST plugin was loaded... [2016-05-16 08:02:43,102][INFO ][plugin.readonlyrest ] [Dust] Readonly REST plugin is enabled. Yay, ponies! [2016-05-16 08:02:43,190][INFO ][plugin.readonlyrest.acl ] ADDING readonlyrest Rules Block :: { name: 'full access to internal servers', policy: ALLOW}

So I think the plugin was well loaded, but when I turn my elasticsearch config to debug mode I see my log full with this lines:

[2016-05-16 08:24:18,151][DEBUG][plugin.readonlyrest.acl ] Block full access to internal servers has matched: full access to internal servers match: true} [2016-05-16 08:24:18,158][DEBUG][plugin.readonlyrest.acl ] matched readonlyrest Rules Block :: { name: 'full access to internal servers', policy: ALLOW}

More or less after a second this lines are printed, but the rule is not blocked my access.

Some ideas? Is the plugin well loaded?

Thanks.

[hecrogu]

Today I saw it when i reinstalled the plugin:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@     WARNING: plugin requires additional permissions     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.lang.reflect.ReflectPermission suppressAccessChecks
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.

Im using java 8, could be some troubles with java8 version?

Thanks.

[sscarduzio]

@hecrogu this plugin is based on reflection and reflection requires an explicit permission from the user. This permission check has been introduced as of ElasticSearch 2.x. So it's normal.