Scripts: Fix security for deprecation warning#28485
Merged
nik9000 merged 3 commits intoelastic:masterfrom Feb 3, 2018
Merged
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
rjernst
approved these changes
Feb 1, 2018
Member
rjernst
left a comment
There was a problem hiding this comment.
Looks good, just one minor question.
| private static final ReadableDateTime EPOCH = new DateTime(0, DateTimeZone.UTC); | ||
|
|
||
| private final SortedNumericDocValues in; | ||
| private final Consumer<String> deprecationCallback; |
Member
There was a problem hiding this comment.
Why do we need this abstracted? Can't the Longs.deprecated method just call deprecationLogger.deprecated directly?
Member
Author
There was a problem hiding this comment.
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.
Member
Author
|
Thanks for reviewing @rjernst! |
nik9000
added a commit
that referenced
this pull request
Feb 4, 2018
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
rjernst
added a commit
to rjernst/elasticsearch
that referenced
this pull request
Jan 9, 2019
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.
rjernst
added a commit
that referenced
this pull request
Jan 10, 2019
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
doPrivilegedcall because it doens't checkElasticsearch's
SpecialPermission.SpecialPermissionis a permissionthat no-script code has and that scripts never have. Usually all
doPrivilegedcalls checkSpecialPermissionto 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