* s3api: store and serve a bucket's PublicAccessBlock configuration
PutPublicAccessBlock, GetPublicAccessBlock and DeletePublicAccessBlock
answered NotImplemented. Store the configuration in the bucket entry's
extended attributes next to the ownership controls, carry it in the
cached BucketConfig, and answer Get on an unset bucket with
NoSuchPublicAccessBlockConfiguration like S3 does.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* s3api: refuse public ACLs when a bucket blocks them
With BlockPublicAcls set, a PutObject, CopyObject, CreateMultipartUpload,
POST Object, PutObjectAcl or PutBucketAcl whose canned ACL or grants name
the AllUsers or AuthenticatedUsers group is refused with AccessDenied.
Private and account grants keep working, so clients that send
x-amz-acl: private on every upload are unaffected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* s3api: ignore public ACL grants for anonymous reads under IgnorePublicAcls
A bucket with IgnorePublicAcls no longer lets an AllUsers grant on the
bucket or on an object answer an anonymous read or listing. Bucket
policies and identity permissions are unaffected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* s3api: reject PublicAccessBlock bodies with unknown elements
A misspelled element such as BlockPublicAcl was ignored, so the request
succeeded and stored the flag as false. Answer MalformedXML instead, and
store the configuration without the request's namespace.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* s3api: fail closed when a bucket's public access block cannot be read
A stored PublicAccessBlock that does not parse now blocks and ignores
public ACLs instead of acting as if none were set. PutBucketAcl and POST
Object return the bucket lookup error rather than skipping the
BlockPublicAcls check when the bucket config cannot be loaded.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* s3api: test BlockPublicAcls on copy, multipart initiate and a PUT-then-GET
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* s3api: keep stored public access block bytes on unrelated bucket updates
An unreadable stored configuration was replaced with the in-memory
all-true fallback whenever another bucket setting was updated, losing
the original value. Write the key only when the update changes the
public access block.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* s3: answer InvalidBucketName to a denied request on a malformed bucket name
The store authorizes a request before it looks at the bucket, so a caller
denied on a bucket whose name breaks the S3 naming rules (upper case, an
underscore, too short, two adjacent periods, a non-ASCII letter) gets 403
AccessDenied, where AWS S3 answers 400 InvalidBucketName. Clients and
compatibility suites that check the error code read the 403 as a permission
problem.
Auth and AuthPostPolicy now turn an AccessDenied for a resolved identity into
InvalidBucketName when the bucket name fails VerifyS3BucketName or uses a
character outside a-z, 0-9, '.' and '-' (VerifyS3BucketName checks with
unicode.IsLower/IsNumber, which accept letters such as 'ü'). The answer depends
on the name alone, so it reveals nothing about which buckets exist. An
authentication failure, an allowed request and a denial on a well-formed name
answer as before.
Test: TestAuthDeniedInvalidBucketName drives iam.Auth with signed and anonymous
requests; on master every malformed name answers 403, with the change 400,
while the identity's own bucket stays allowed and a well-formed foreign name
stays 403. TestRefineDenialForBucketName covers the rule table.
* s3: refine POST-policy and deferred anonymous-read denials on a malformed bucket name
Two denial paths bypass the refinement in Auth and AuthPostPolicy:
- A browser POST upload carries its credentials in the form, so
AuthPostPolicy delegates it to PostPolicyBucketHandler, which verifies the
form and writes AccessDenied itself when the signer may not write the bucket
or the per-key authorization denies the object. Both denials now go through
refineDenialForBucketName with the verified identity.
The coarse Write check used to run inside doesPolicySignatureV2Match and
doesPolicySignatureV4Match before the signature was compared, so a form with
a wrong signature was told whether the key may write the bucket. It now runs
in doesPolicySignatureMatch after the signature verifies, as on the
header-signed path; a form that fails verification answers
SignatureDoesNotMatch (or MissingFields) and is never refined.
- Unsigned GET/HEAD object reads are deferred by AuthWithPublicRead to the
object handlers, where writeAnonymousAwareNotFound masks a miss as
AccessDenied. That denial is refined with the anonymous identity, so a
missing malformed bucket answers InvalidBucketName when an anonymous
identity is configured, as Auth does. A denial on an entry that was found
is left alone: the bucket exists.
Test: TestPostPolicyDeniedInvalidBucketName drives AuthPostPolicy with signed
forms (Write denied, per-key policy deny, bad signature, well-formed name);
TestAnonymousReadDeniedInvalidBucketName drives AuthWithPublicRead with GET and
HEAD, with and without an anonymous identity. Both fail before this change.
* s3: refine a denied anonymous read of an existing key on a malformed bucket name
A deferred anonymous GET/HEAD refined only its masked miss to
InvalidBucketName, so in a bucket whose name breaks the S3 rules (one
VerifyS3BucketName still accepts, such as a non-ASCII name) a missing key
answered 400 and an existing private key 403, telling the caller which
keys exist. The entry check now refines its denial the same way, so both
answer alike. Without an anonymous identity no identity resolves and both
stay 403, as in Auth.
The deny-precedence case in TestAnonymousObjectACLConfiguredIdentity runs
on the fixture bucket "b", shorter than S3's three-character minimum, so
its denial now answers InvalidBucketName.
---------
Co-authored-by: Javier de la Torre <jatorre@lakehousebox.com>
* fix(s3): honor object ACLs for anonymous reads
Signed-off-by: zhaoyuchen <43179751+zhao-yc@users.noreply.github.com>
* s3: drop unsigned session tokens on deferred anonymous reads
An unsigned GET/HEAD carrying X-Amz-Security-Token is anonymous, not a
session request; strip the token before authentication and authorization
so it cannot influence identity or policy evaluation.
Generated with [Devin](https://devin.ai)
Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
---------
Signed-off-by: zhaoyuchen <43179751+zhao-yc@users.noreply.github.com>
Co-authored-by: Chris Lu <chrislusf@users.noreply.github.com>
Co-authored-by: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com>
