Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Enable securitymanager #10717
We have been using this in our tests for some time. Recently the permissions have gotten reasonable where we don't need read/write access everywhere.
I think we should start ES with securitymanager (just like tomcat and other things) to enhance security.
I ran the lucene benchmark suite comparing security manager off/on and there is no difference. I think a lot of concerns about perceived performance differences don't really make sense if you are managing files and sockets properly.
Here is a prototype, i tried to keep it simple (but damn if the SSD detection and other stuff we have going on fights me on that). There is nothing to configure, though security manager can be disabled in elasticsearch.yml or whatever with
We use the same actual policy file for both tests and bin/elasticsearch. We just add additional permissions based on the environment (e.g. data paths and so on) so things will work.
I didnt write any tests yet, but I can add some unit tests for the stuff here.
referenced this pull request
Apr 23, 2015
this change looks good to me - i am curious if we see per drops with this enabled by default etc. but I even if we do we should push this (plus unittests please) and move the decision to default enable it to a different issue if we need to. I really like that we can offer this to the users and I am really leaning towards enable by default!
I tested indexing tiny (log line) docs, same test I run at http://benchmarks.elastic.co.
I ran each of master and this branch two times...
Master is 8999.7 and 9160.0 docs/sec overall (6.9 M docs), while this branch is 9610.9 and 9835.4 docs/sec.
Net/net I don't think security manager hurts indexing performance!
Very promising on the perf test, its great. I will fix the logging post your push, I think that we should also work on a different issue on getting the test permissions out of this file, since it will be confusing for users who look at it, even though those env vars are not set.
I made the policy file a resource (not in conf/) and removed the docs of the option in elasticsearch.yml. Someone can turn it off with security.manager.enabled=false if they dont like it. And they can set JVM_OPTS with -D's to do whatever their heart desires rather than us supporting plumbing. I also added some really simple unit tests so we had something.
I don't think we should have lots of logic to look if security manager is already set, to look if this or that system property is already set. There is no need or use-case for this IMO. It will just make our codebase even bigger than i already is.
Having a custom security policy is extremely expert. Those users can turn it off with the boolean i provided here.
We only need one way to do this. This isn't perl.
added a commit
this pull request
Apr 24, 2015
Apr 24, 2015
1 check passed
I agree, it will surely breaks things here and there. But in the case of snapshot repositories of type