Skip to content
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

Add a config option to limit request body size #276

Merged
merged 11 commits into from
Sep 17, 2024

Conversation

andrew4699
Copy link
Contributor

Description

Adds a config option to limit the request body size. This is useful to prevent DoS-style attacks before the request moves further through the request handlers.

Type of change

  • New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

  • Added an integration test
  • Existing tests work
  • Ran Polaris with no limit, a small limit, and a high limit, and verified that the behavior was as expected

Checklist:

Please delete options that are not relevant.

  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings
  • If adding new functionality, I have discussed my implementation with the community using the linked GitHub issue

polaris-server.yml Outdated Show resolved Hide resolved
polaris-server.yml Outdated Show resolved Hide resolved
Comment on lines 155 to 157
public long getMaxDocumentBytes() {
return maxDocumentBytes;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should have a default value.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Checking a bit more about class StreamReadConstraints. -1 is the right default value, which means no limit.

        public Builder maxDocumentLength(long maxDocLen) {
            if (maxDocLen <= 0L) {
                maxDocLen = -1L;
            }

            this.maxDocLen = maxDocLen;
            return this;
        }

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for pulling this up, this actually makes me more strongly interested in 0. Please see my new comment below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also find 0-as-unlimited a little confusing. I agree that if we make the default -1 it might imply that 0 is different from -1, but I also think a default of 0 is going to raise some questions.

Maybe we should just disallow 0, since StreamReadConstraints doesn't support what 0 would intuitively mean ("reject all requests")

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the code from StreamReadConstraints, that means both 0 and -1 are considered no limits. But I think it does make sense to have -1 for unlimited and disallow 0.

Copy link
Contributor Author

@andrew4699 andrew4699 Sep 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I updated it to default to -1, explained what -1 is, and restricted 0 with an exception/useful comment. I agree that -1 is a better indicator of "no limit" and restricting 0 solves some ambiguity.

@andrew4699
Copy link
Contributor Author

andrew4699 commented Sep 10, 2024

I agree with the reasons for wanting to make -1 the default value, but I'd like to offer a counterargument for why it may make sense to keep it at 0 in this case:

  • As this comment shows, both 0 and -1 disable the limit. Listing -1 may falsely lead the user to believe that 0 is different.
  • Default value compatibility across JSON/YAML serializers. With the default set to 0, you don't have to worry about whether your serialization library respects your default value nor what it does with unspecified fields.

@flyrain
Copy link
Contributor

flyrain commented Sep 10, 2024

I'm fine with either -1 or 0. My main concern with using 0 is that there is a chance that it might be misunderstood as a valid limit rather than indicating "no limit." In contrast, -1 is less ambiguous in this context. Additionally, I recommend defining a constant for clarity:

private static final long DOCUMENT_BYTES_NO_LIMIT = -1;

@@ -167,3 +167,5 @@ logging:
archivedLogFilenamePattern: ./logs/polaris-%d.log.gz
# The maximum number of log files to archive.
archivedFileCount: 14

maxDocumentBytes: 0 # Don't set a limit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. This comment would ideally not be inline
  2. Do we really want to call this maxDocumentBytes? What is a "Document" in the context of a Polaris instance?
  3. Whatever we call it, we might put a small comment explaining what this is

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed to maxRequestBodyBytes and updated/moved the comment.

@andrew4699
Copy link
Contributor Author

Just updated a couple of things:

  • Renamed maxDocumentBytes to maxRequestBodyBytes
  • Changed the default to -1 and made it throw an exception if you try to use 0, since the underlying implementation treats 0 and -1 as the same and we don't want to trick the user into thinking 0 actually does something different
  • Improved comments in the config
  • Added an additional test validating that there's already an existing limit on total header size

// we block 0 to prevent ambiguity.
throw new IllegalArgumentException(
String.format(
"maxRequestBodyBytes may not be 0. Use %d to specify no limit.",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "maxRequestBodyBytes must be a positive integer or %d to specify no limit."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

@@ -146,6 +149,23 @@ public void setFeatureConfiguration(Map<String, Object> featureConfiguration) {
this.configurationStore = new DefaultConfigurationStore(featureConfiguration);
}

@JsonProperty("maxRequestBodyBytes")
public void setMaxRequestBodyBytes(long maxRequestBodyBytes) {
if (maxRequestBodyBytes == 0) {
Copy link
Contributor

@eric-maynard eric-maynard Sep 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Maybe we should constrain this to a positive integer or -1 while we're at it

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to restrict all but -1

flyrain
flyrain previously approved these changes Sep 12, 2024
Copy link
Contributor

@flyrain flyrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with one minor question.

@@ -146,6 +149,23 @@ public void setFeatureConfiguration(Map<String, Object> featureConfiguration) {
this.configurationStore = new DefaultConfigurationStore(featureConfiguration);
}

@JsonProperty("maxRequestBodyBytes")
public void setMaxRequestBodyBytes(long maxRequestBodyBytes) {
if (maxRequestBodyBytes == 0) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we consider throwing an exception when the configured value for maxRequestBodyBytes is less than -1 (e.g., -2, -100)? While the underlying library can technically handle these values, I believe we should restrict any negative number except for -1, which is already treated as "unlimited." This is consistent with our approach of throwing an exception for a value of 0.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated to restrict all but -1

Copy link
Contributor

@eric-maynard eric-maynard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM with some optional nits. Thanks for the change!

* limits
*/
public class RequestThrottlingErrorResponse {
public enum Error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Error is a name from java.lang - can you choose something different here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Comment on lines 156 to 157
// same, so
// we block all but -1 to prevent ambiguity.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: This formatting looks a bit odd. Can it be 2 lines?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

I've just been letting spotless take the wheel with these, but I guess it's ok with either style? We should probably update it to prefer a single format if possible.

flyrain
flyrain previously approved these changes Sep 16, 2024
Copy link
Contributor

@flyrain flyrain left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 with a minor suggestion

Comment on lines 154 to 161
if (maxRequestBodyBytes <= 0 && maxRequestBodyBytes != -1) {
// The underlying library that we use to implement the limit treats all values <= 0 as the
// same, so we block all but -1 to prevent ambiguity.
throw new IllegalArgumentException(
String.format(
"maxRequestBodyBytes must be a positive integer or %d to specify no limit.",
REQUEST_BODY_BYTES_NO_LIMIT));
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor suggestion:

Preconditions.checkArgument(condition, message);

@flyrain flyrain merged commit 68b248a into apache:main Sep 17, 2024
3 checks passed
@flyrain
Copy link
Contributor

flyrain commented Sep 17, 2024

Thanks @andrew4699 for working on this. Thanks @snazy @eric-maynard for the review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants