fix(s3): authorize a configuring CreateBucket per setting, and populate the ACL condition keys

[vieiralucas]

Summary

CreateBucket was authorized as s3:CreateBucket alone (plus s3:TagResource for a tag set), even though it applies x-amz-acl / x-amz-grant-*, x-amz-object-ownership and object-lock enablement. On AWS each of those needs its own permission.

This got worse when #2558 made those settings persist: a principal holding only s3:CreateBucket could create a public-read bucket that used to lose the grant on restart and now keeps it — a transient gap became durable over-permission.

Second of the three gaps documented as out of scope in #2558.

What it does

The create returns one action per setting the request configures, following the Permissions section of CreateBucket in the vendored Smithy model:

Request carries	Also required
CreateBucketConfiguration tag set	s3:TagResource
an ACL granting beyond the owner	s3:PutBucketAcl
x-amz-object-ownership	s3:PutBucketOwnershipControls
x-amz-bucket-object-lock-enabled: true	s3:PutBucketObjectLockConfiguration + s3:PutBucketVersioning

Dispatch already requires every returned action to be allowed, so a principal with only s3:CreateBucket can still create a plain bucket.

The ACL rule follows that documentation precisely rather than keying on header presence: an ACL set to public-read, public-read-write, authenticated-read "or any other custom ACLs" needs s3:PutBucketAcl, while "if you set the ACL to private, or if you don't specify any ACLs, only the s3:CreateBucket permission is required". It's judged by the grants the request resolves to, so a least-privilege caller that always sends --acl private — Terraform's legacy acl attribute, SDK wrappers that always set one — is not refused where real S3 succeeds.

Condition keys

s3:x-amz-acl and the s3:x-amz-grant-* family are populated now. They're how a policy pins down which ACL a write may ask for, and while they were never emitted a guardrail like

{"Effect":"Allow","Action":"s3:CreateBucket","Resource":"*",
 "Condition":{"StringEquals":{"s3:x-amz-acl":"private"}}}

matched nothing and silently authorized exactly what it was written to block. They're emitted from the headers on any request that carries them, rather than gated on an action list that would drift. An absent header emits nothing, so a condition on it safe-fails to "does not apply" — and a blank x-amz-grant-* header emits nothing either, for the same reason has_grant_headers treats it as absent: the request asks for no grant, and a present key would make a Null-based guardrail deny it.

Test plan

• Unit (481 passing): one action per setting, including private adding none, a false object-lock header adding none, and all four settings at once in a single authorization set; condition keys populated from x-amz-acl and a grant header, and absent headers emitting nothing.
• E2E (iam_enforcement): a least-privilege principal refused for a public-read create and unblocked by adding s3:PutBucketAcl, with the resulting bucket verified public-read; --acl private accepted with only s3:CreateBucket; the object-lock pair refused then unblocked; and a condition-keyed policy admitting private while denying public-read.
• Suites: fakecloud-s3 481 passed; e2e iam_enforcement + iam_enforcement_abac 65 passed; e2e s3 + s3_persistence 119 passed; fakecloud-conformance --test s3 51 passed. cargo clippy --all-targets -- -D warnings and cargo fmt --check clean.
• Conformance exposure: none — iam_actions_for / iam_condition_keys_for are only reached when IAM is enabled, and the conformance runner never enables --iam.

Surface sync

• Reference docs — website/content/docs/reference/security.md adds s3:x-amz-acl and the s3:x-amz-grant-* family to the supported service-condition-key table; website/content/docs/services/s3.md documents the per-setting permissions, including the private exemption.
• SDKs / introspection — no change: AWS authorization behavior, not a /_fakecloud/* surface.
• Counts / metadata — unchanged: no new operation, service or conformance variant.

---

Summary by cubic

CreateBucket was authorized by s3:CreateBucket alone, so a principal holding only that permission could configure ACLs, object ownership, or object lock at create time. Since those settings persist, that transient gap became durable over-permission. The create now requires one action per setting it configures, and the associated s3:x-amz-* condition keys are populated from headers.

• Required actions follow the model's CreateBucket permissions: s3:PutBucketAcl, s3:PutBucketOwnershipControls, and s3:PutBucketObjectLockConfiguration plus s3:PutBucketVersioning for object lock; --acl private and no-ACL creates still need only s3:CreateBucket.
• The ACL check and the BucketOwnerEnforced conflict check share one acl_reaches_past_owner helper, so aws-exec-read no longer escapes the s3:PutBucketAcl requirement; on its own operations the implied actions carry none of the create's tags.
• The create's requested tags populate aws:RequestTag for every implied action, so a tag-scoped guardrail that permits the create doesn't then deny the ACL or object-lock action it implies.
• Condition keys emit from any header that carries them (s3:x-amz-acl, the s3:x-amz-grant-* family, s3:x-amz-object-ownership); absent or blank values emit nothing, so a Null-based guardrail can't deny a request that asks for nothing. The object-lock header emits no key, since AWS defines none for it; that setting is gated by permissions only.
• Reference docs and the S3 service page document the per-setting permissions and the new condition keys.

^{Written for commit be39a83. Summary will update on new commits.}