-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Scripts: Fix security for deprecation warning #28485
Conversation
If you call `getDates()` on a long or date type field add a deprecation warning to the response and log something to the deprecation logger. This *mostly* worked just fine but if the deprecation logger happens to roll then the roll will be performed with the script's permissions rather than the permissions of the server. And scripts don't have permissions to, say, open files. So the rolling failed. This fixes that by wrapping the call the deprecation logger in `doPriviledged`. This is a strange `doPrivileged` call because it doens't check Elasticsearch's `SpecialPermission`. `SpecialPermission` is a permission that no-script code has and that scripts never have. Usually all `doPrivileged` calls check `SpecialPermission` to make sure that they are not accidentally acting on behalf of a script. But in this case we are *intentionally* acting on behalf of a script. Closes elastic#28408
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.
Looks good, just one minor question.
@@ -177,15 +206,27 @@ public int size() { | |||
private static final ReadableDateTime EPOCH = new DateTime(0, DateTimeZone.UTC); | |||
|
|||
private final SortedNumericDocValues in; | |||
private final Consumer<String> deprecationCallback; |
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.
Why do we need this abstracted? Can't the Longs.deprecated method just call deprecationLogger.deprecated directly?
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 could but then I couldn't test this. There isn't any consistent way to make it fail without this funny unit test dance that I do because it usually only fails when you rotate the log files. At least, that is the only time I could get it to fail locally.
Thanks for reviewing @rjernst! |
If you call `getDates()` on a long or date type field add a deprecation warning to the response and log something to the deprecation logger. This *mostly* worked just fine but if the deprecation logger happens to roll then the roll will be performed with the script's permissions rather than the permissions of the server. And scripts don't have permissions to, say, open files. So the rolling failed. This fixes that by wrapping the call the deprecation logger in `doPriviledged`. This is a strange `doPrivileged` call because it doens't check Elasticsearch's `SpecialPermission`. `SpecialPermission` is a permission that no-script code has and that scripts never have. Usually all `doPrivileged` calls check `SpecialPermission` to make sure that they are not accidentally acting on behalf of a script. But in this case we are *intentionally* acting on behalf of a script. Closes #28408
When the deprecation log is written to within scripting support code like ScriptDocValues, it runs under the reduces privileges of scripts. Sometimes this can trigger log rolling, which then causes uncaught security errors, as was handled in elastic#28485. While doing individual deprecation handling within each deprecation scripting location is possible, there are a growing number of deprecations in scripts. This commit wraps the logging call within the deprecation logger use a doPrivileged block, just was we would within individual logging call sites for scripting utilities.
…37281) When the deprecation log is written to within scripting support code like ScriptDocValues, it runs under the reduces privileges of scripts. Sometimes this can trigger log rolling, which then causes uncaught security errors, as was handled in #28485. While doing individual deprecation handling within each deprecation scripting location is possible, there are a growing number of deprecations in scripts. This commit wraps the logging call within the deprecation logger use a doPrivileged block, just was we would within individual logging call sites for scripting utilities.
If you call
getDates()
on a long or date type field add a deprecationwarning to the response and log something to the deprecation logger.
This mostly worked just fine but if the deprecation logger happens to
roll then the roll will be performed with the script's permissions
rather than the permissions of the server. And scripts don't have
permissions to, say, open files. So the rolling failed. This fixes that
by wrapping the call the deprecation logger in
doPriviledged
.This is a strange
doPrivileged
call because it doens't checkElasticsearch's
SpecialPermission
.SpecialPermission
is a permissionthat no-script code has and that scripts never have. Usually all
doPrivileged
calls checkSpecialPermission
to make sure that theyare not accidentally acting on behalf of a script. But in this case we
are intentionally acting on behalf of a script.
Closes #28408