Upgraded from 5.4.0 to 5.6.0 Now wont start

cronin · 2017-09-13 15:54:04 UTC

I am hoping to get a bit of help. I just upgraded elastic from 5.4.0 to 5.6.0 and not elastic is refusing to start I checked the logs and I am seeing the following error. Any help would be great.

[2017-09-13T15:49:02,198][ERROR][o.e.b.Bootstrap ] Guice Exception: java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” “read”)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at sun.nio.fs.UnixChannelFactory.open(UnixChannelFactory.java:245)
at sun.nio.fs.UnixChannelFactory.newFileChannel(UnixChannelFactory.java:136)
at sun.nio.fs.UnixChannelFactory.newFileChannel(UnixChannelFactory.java:148)
at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:212)
at java.nio.file.Files.newByteChannel(Files.java:361)
at java.nio.file.Files.newByteChannel(Files.java:407)
at java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:384)
at java.nio.file.Files.newInputStream(Files.java:152)
at org.elasticsearch.common.settings.Settings$Builder.loadFromPath(Settings.java:1032)
at org.elasticsearch.plugin.readonlyrest.es.SettingsManagerImpl.getCurrentSettings(SettingsManagerImpl.java:55)
at org.elasticsearch.plugin.readonlyrest.configuration.ReloadableSettings.(ReloadableSettings.java:50)
at org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl.(ReloadableSettingsImpl.java:29)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at <<>>
at org.elasticsearch.node.Node.(Node.java:499)
at org.elasticsearch.node.Node.(Node.java:245)
at org.elasticsearch.bootstrap.Bootstrap$5.(Bootstrap.java:233)
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:233)
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:342)

sscarduzio · 2017-09-13 15:57:58 UTC

Hello @cronin, you surely will get some help.
can you run this command on your elasticsearch installation?

cat plugins/readonlyrest/plugin-descriptor.properties

So I can check what exact plugin version is this.

cronin · 2017-09-13 16:00:56 UTC

Sure!

name=readonlyrest
version=1.16.10
description=Safely expose Elasticsearch REST API
classname=org.elasticsearch.plugin.readonlyrest.es.ReadonlyRestPlugin
java.version=1.8
elasticsearch.version=5.6.0

ES 2.x compatibility

site=false
jvm=true
isolated=false

sscarduzio · 2017-09-13 16:09:25 UTC

Oh I see what’s wrong. The new experimental code to read the settings from readonlyrest.yml ended up in the 5.5.3 and 5.5.0 because Elastic has released those new version right after ROR 1.16.10 was released.

A fix is coming, hold on @cronin.

sscarduzio · 2017-09-13 16:20:12 UTC

Can you please try again with this build?

https://readonlyrest-data.s3-eu-west-1.amazonaws.com/tmp/readonlyrest-1.16.11-pre4_es5.6.0.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJEKIPNTOTIVGQ4EQ/20170913/eu-west-1/s3/aws4_request&X-Amz-Date=20170913T161938Z&X-Amz-Expires=604800&X-Amz-SignedHeaders=host&X-Amz-Signature=52d1861bf74bb869be4f0f0cfe44dda502fba81dd7b43482b9e460a2a5887d51

cronin · 2017-09-13 16:50:27 UTC

YES! Worked perfect!!!

Now upgrading Kibana and installing ROR Enterprise. Very exciting.

sscarduzio · 2017-09-13 16:54:28 UTC

Awesome! If you have any questions or issues, just tell me. Enjoy!

cronin · 2017-09-13 17:51:09 UTC

Follow up question in ROR Enterprise how do I enable the “Group/Tenancy selector” in Kibana?

sscarduzio · 2017-09-13 18:37:38 UTC

Hi @cronin, see the video and attached configuration example here:

cronin · 2017-09-13 20:01:36 UTC

Thanks for this I’m noticing some odd:
When I make changes to ROR settings in my .yml file they don’t take hold when I look back in Kibana I still see my old settings. is this intential? Should I make all chnages moving forward in Kibana?

sscarduzio · 2017-09-13 20:28:29 UTC

Yes the Settings UI saves the configuration on an index, and the index settings have priority at node start up.

The lifecycle of the settings is intended like this

Set up the basic failsafe credentials and ACL in the ES node’s YAML file (i.e. credentials for kibana server, logstash, and ROR admin).
Get the Kibana plugin up and running and log in as administrator
Open the Settings UI from Kibana. If this is the first time, it will inherit whatever settings it reads from the YAML file (to give you a starting point)
Tweak the settings, hit the commit button and they are saved in the .readonlyrest index (ES settings automatically picks up the changes)
From now on, even if you restart the ES node, the settings are going to be loaded exclusively from the .readonlyrest index and can be edited from Kibana only.

If you want to revert to file-based settings

back up the YAML you see in the Settings UI
write those settings to the node’s YAML file
delete the readonlyrest index from ES
restart the node

cronin · 2017-09-13 23:05:18 UTC

Okay @sscarduzio last few question I swear…
Currently when applying kibana rw rules Im applying them at the group level like so:
name: "::XXX::"
groups: [“XXX”]
kibana_index: ".kibana_xxx"
kibana_access: rw

But can I apply them at the user level instead like this:
users:

username: greg
auth_key_sha256: "ABC"
kibana_access: rw
groups: [“XXX”]

#groups Below
name: "::XXX::"
groups: [“XXX”]
kibana_index: “.kibana_xxx”

Also same question for kibana_hide_apps.

sscarduzio · 2017-09-14 07:40:15 UTC

Hi @cronin, in the blocks under under the “users” section you should only have the “group” rule to define what groups are associated to this user, and some authentication related rule (e.g. auth_key, auth_key_sha256, etc).
Although some more advanced things are possible like LDAP + local groups. But that’s another story.

Does this answer your question?

cronin · 2017-09-14 12:15:00 UTC

Not exactly. Let me rephrase a bit here is an example of my new user settings:
-
name: "::XXX::"
groups: [“XXX”]
kibana_index: “.kibana_XXX”
-
name: "::XXX_RO::"
groups: [“XXX RO”]
kibana_index: ".kibana_XXX"
kibana_access: ro
kibana_hide_apps: [“readonlyrest_kbn”, “timelion”, “kibana:management”, “kibana:discover”, “kibana:visualize”, “kibana:dev_tools”]
users:

username: greg
auth_key_sha256: "XYZ"
groups: [“XXX”, “XXX RO”]

Now this works as expeted however the readonly group “XXX RO” can still edit and crate items in dashbaords. My understanding is that the “RO” flag would prevent that from happening.

sscarduzio · 2017-09-14 13:31:38 UTC

I’m testing this with the example settings you provided. One thing I didn’t mention is that all indices need to be lowercase, the example should have kibana_index: ".kibana_xxx"

Beside that, to your point. I actually reproduced the issue in the sense that I could get a green confirmation message when I add a viusalization to the dashboard, but when I refresh my dashboard doesn’t have the visualization added.
Can you confirm you see the same?

cronin · 2017-09-14 14:04:47 UTC

Yes, that’s exactly what I’m saying. Also if you edit a dashboard edit an element and save you get a 400 error and then logged out.

cronin · 2017-09-14 14:06:05 UTC

Also to your point all my indexes are lowercase I just removed client names and replaced with XXX.

sscarduzio · 2017-09-14 14:12:57 UTC

So basically the expected behaviour would be to get the 400 without the logout, I guess?

cronin · 2017-09-14 14:47:05 UTC

I mean to be honest the ideal scenario would be if you have RO access you shouldn’t even see the Edit buttons in the UI I mean what’s the point if you can only read?

But yes if that’s not possible there should be no logout just a 400 that it couldn’t save.

areacarranza · 2017-09-18 19:47:17 UTC

Hi Simone

I have the same problem starting elasticsearch 5.6.

Error injecting constructor, java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” "$
at org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl.(Unknown Source)
while locating org.elasticsearch.plugin.readonlyrest.es.ReloadableSettingsImpl
for parameter 5 at org.elasticsearch.plugin.readonlyrest.es.IndexLevelActionFilter.(Unknown Source)
while locating org.elasticsearch.plugin.readonlyrest.es.IndexLevelActionFilter
while locating org.elasticsearch.action.support.ActionFilter annotated with @org.elasticsearch.common.inject.multibindings.Element(setNam$
at unknown
while locating java.util.Set<org.elasticsearch.action.support.ActionFilter>
for parameter 0 at org.elasticsearch.action.support.ActionFilters.(Unknown Source)
while locating org.elasticsearch.action.support.ActionFilters
for parameter 2 at org.elasticsearch.index.reindex.TransportDeleteByQueryAction.(Unknown Source)
while locating org.elasticsearch.index.reindex.TransportDeleteByQueryAction
Caused by: java.security.AccessControlException: access denied (“java.io.FilePermission” “config/readonlyrest.yml” “read”)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)

This is my plugin version

name=readonlyrest
version=1.16.10
description=Safely expose Elasticsearch REST API
classname=org.elasticsearch.plugin.readonlyrest.es.ReadonlyRestPlugin
java.version=1.8
elasticsearch.version=5.6.0

Could you help me please

regards