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)
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.
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?
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.
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:
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.
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:
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.
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?
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.
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