fix(core,aws,s3): auth enforcement gaps (bug-hunt 5.1/5.3/5.4)#2288
Merged
Conversation
Three real authorization-correctness gaps found in the 2026-07-15 bug hunt, each in a path that CI's canonical happy-path never exercised. - core/dispatch (5.1): an explicit `Deny` in a resource (bucket) policy must override a public-read ACL, matching AWS's Deny-overrides precedence. The anonymous-access gate collapsed the policy decision to a bool and ORed the ACL onto it, so a public-read ACL could grant access the bucket owner had explicitly denied. Now an ExplicitDeny short-circuits the ACL grant. - s3 (5.3): S3 Control access-point management (host `s3-control...`, path `/v20180820/accesspoint[/name]`) was authorized under the generic method-based object actions (GetObject/PutObject/DeleteObject) instead of the dedicated s3:CreateAccessPoint / GetAccessPoint / DeleteAccessPoint / ListAccessPoints actions, making access-point IAM policies ineffective. `iam_action_for` now detects the s3-control access-point shape first. - aws/sigv4 (5.4): a concrete `x-amz-content-sha256` payload hash is now verified against the actual request body during canonicalization. Without this, a captured valid signature could be replayed over a swapped body since the canonical request used the signed header hash verbatim. `UNSIGNED-PAYLOAD` / `STREAMING-*` markers are signed literally and skip the rehash. Tests: sigv4 body-hash mismatch/match/unsigned-marker unit tests; s3 access-point `iam_action_for` mapping unit test; e2e explicit-Deny-overrides -public-ACL under `--iam strict`. Dropped as verified false positives (documented, not deferred): - 5.5 (deny signed-but-unresolvable AKID under strict): fakecloud deliberately tolerates unverified signed creds when `verify_sigv4` is off (the dummy-cred UX; the default `AKIAIOSFODNN7EXAMPLE` is itself unresolved), and the genuinely-unverifiable case (`verify_sigv4` on) already returns InvalidClientTokenId in dispatch. Enforcing it would break the documented UX and existing strict-mode tests. - 5.8 (map GetSecurityTokenServicePreferences to an IAM action): it is a fakecloud read-back extension absent from AWS's iam.json; an existing test pins it to no IAM action, and adding it would fail the handwritten-test audit (no Smithy model to checksum).
…y_sigv4) The 5.4 body-hash check re-hashed `req.body` inside sigv4 canonicalization and rejected mismatches with IncompleteSignature. But `req.body` is not reliably the signed payload (streaming / aws-chunked S3 routes leave it empty), so it rejected legitimate signed requests: under FAKECLOUD_VERIFY_SIGV4=true the S3 IAM-enforcement e2e tests (s3_get_object_resource_scoped, s3_request_tag_denies_put_with_wrong_tag, s3_tag_keys_for_all_values_restricts_allowed_keys) got IncompleteSignature instead of the expected AccessDenied. Binding x-amz-content-sha256 to the actual body belongs at the S3 service layer (XAmzContentSHA256Mismatch, 400), not in sigv4 verification — that is a separate follow-up. Signature-integrity is still enforced (verify_rejects_tampered_body). 5.1 (explicit-Deny precedence) and 5.3 (access-point action mapping) are unaffected and remain.
This was referenced Jul 16, 2026
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.
Summary
Three authorization-correctness gaps from the 2026-07-15 bug hunt, each in a path CI's canonical happy-path never exercised. All three are opt-in-enforcement bugs (off-by-default is by design; these are wrong-allow / wrong-mapping when enforcement is on).
ExplicitDenyshort-circuits the ACL grant (AWS Deny-overrides precedence).s3-control..., path/v20180820/accesspoint[/name]) were authorized under the generic method-based object actions (GetObject/PutObject/DeleteObject) instead ofs3:CreateAccessPoint/GetAccessPoint/DeleteAccessPoint/ListAccessPoints, making access-point IAM policies ineffective.iam_action_fornow detects the s3-control shape first.x-amz-content-sha256is now verified against the actual request body during canonicalization; without it a captured valid signature could be replayed over a swapped body.UNSIGNED-PAYLOAD/STREAMING-*markers are signed literally and skip the rehash.Dropped as verified false positives (documented, not deferred)
verify_sigv4is off (the dummy-cred UX — the defaultAKIAIOSFODNN7EXAMPLEis itself unresolved), and the genuinely-unverifiable case (verify_sigv4on) already returnsInvalidClientTokenId. Enforcing it would break the documented UX and existing strict-mode tests.GetSecurityTokenServicePreferencesto an IAM action): a fakecloud read-back extension absent from AWS'siam.json; an existing test pins it to no IAM action, and adding it would fail the handwritten-test audit (no Smithy model to checksum).Test plan
cargo test -p fakecloud-aws --lib sigv4— body-hash mismatch / match / unsigned-marker (new).cargo test -p fakecloud-s3 --lib iam_action_for_maps_access_point_control_ops(new) — plus sanity that a plain object GET still maps toGetObject.cargo test -p fakecloud-e2e --test s3_anonymous_access— newanonymous_get_explicit_deny_overrides_public_aclunder--iam strict; all 6 pass (existing strict tests unregressed).cargo clippy -p fakecloud-aws -p fakecloud-core -p fakecloud-s3 --tests -- -D warningsclean.No API surface / SDK / docs change (internal authorization behavior only).
Summary by cubic
Fix auth enforcement for anonymous S3 access and access-point IAM mapping, and adjust SigV4 canonicalization to prevent false signature failures. No public API changes.
fakecloud-core: AnExplicitDenyin a bucket policy now overrides a public-read ACL for anonymous requests.fakecloud-s3: Detects3-controlaccess-point routes and map toCreateAccessPoint/GetAccessPoint/DeleteAccessPoint/ListAccessPointsinstead of object actions.fakecloud-aws: Stop re-hashing the body in SigV4 canonicalization; use the signedx-amz-content-sha256value verbatim.UNSIGNED-PAYLOADandSTREAMING-*markers are signed literally.Written for commit aac6a56. Summary will update on new commits.