New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable securitymanager #10717
Enable securitymanager #10717
Conversation
Security.configure(environment); | ||
logger.info("security enabled"); | ||
} else { | ||
logger.info("security disabled"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be a warning?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If its disabled lets issue a warning.
this logic has been refactored. Log a warning when security is disabled.
Conflicts: src/main/java/org/elasticsearch/env/NodeEnvironment.java
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! |
logger.info("security enabled"); | ||
} else { | ||
logger.warn("security disabled"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we debug log the default? also leaning to have info the "non default" setting, thats what we try to do most times in other components to try and keep the startup logs clean and informative.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is officially back and forth at this point. I started at info and went to warn based on feedback. Guys get your shit together, im not playing this game.
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! |
Unless someone can find real performance issues or problems, i plan to push the change in 72 hours. And you guys can bikeshed logging levels somewhere else, im not doing that. |
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 can remove the logging completely. i am happy with no logging and for someone else to deal with logging completely. its such a ridiculous thing to make bikesheds out of. I will not add any more logging statements to this codebase, trust me. |
logging is removed. |
LGTM, lets push it |
Remove exposed boolean to turn off security. Add unit test
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. |
@@ -92,6 +91,12 @@ public boolean handle(int code) { | |||
}); | |||
} | |||
} | |||
|
|||
private void setupSecurity(Settings settings, Environment environment) throws Exception { | |||
if (settings.getAsBoolean("security.manager.enabled", true)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we make "security.manager.enabled"
a constant please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is a constant. Just like all the other strings in this file :)
So I will add it, but I will do so under protest:
- there are zero named constants in this file, I am just matching the style surrounding the code, for consistency.
- named constants only used once just cause indirection hurt locality of reference to those reading the code.
In general, named constants considered harmful.
left one tiny nitpick - LGTM otherwise feel free to push after fixing the nitpick :) |
LGTM, @rmuir if someone provides the |
Someone with a custom policy will have to also use the option (security.manager.enabled=false) to disable what we are doing. |
@rmuir I see, will it be trappy? which one will be applied if just |
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. |
@rmuir sounds good |
@rmuir sorry to come a day after the fair but I think this change prevents writing in a local FsRepository no? |
Probably. I have no idea about this one in particular, but i am sure this change breaks all kinds of things using rogue paths etc. We should likely review all places using paths.get and open bugs for anything except environment that uses it. |
I agree, it will surely breaks things here and there. But in the case of snapshot repositories of type |
Why doesnt that feature use a path configured in environment like all other paths. That is the way to fix it imo |
I agree this should not be outside of the path or we need to have a dedicated path that is configured. |
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
security.enabled=false
.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.