New S3 bucket ownership default breaks the S3 streamwrapper mkdir method.

[tbenice]

Describe the bug

April 2023 S3 started defaulting all new buckets to 'Bucket owner enforced' ownership setting (https://aws.amazon.com/about-aws/whats-new/2022/12/amazon-s3-automatically-enable-block-public-access-disable-access-control-lists-buckets-april-2023/) . Because of this, any createbucket call with acl settings returns a 400 error "InvalidBucketAclWithObjectOwnership".

This would be fine except that the streamwrapper class mkdir method uses acls by default, and so any use of mkdir returns the 400 error.

Expected Behavior

Using mkdir method of the streamwrapper class should create a bucket successfully.

Current Behavior

mkdir method always returns a 'InvalidBucketAclWithObjectOwnership' error.

Reproduction Steps

mkdir("s3://my-bucket-name");

Possible Solution

in the mkdir method try creating the bucket using 'DeleteBucketOwnershipControls' to allow acls, or remove any acl setting from the method.

Additional Information/Context

No response

SDK version used

^3.0

Environment details (Version of PHP (php -v)? OS name and version, etc.)

php 8, macos, Pantheon hosting environment.

[stobrien89]

Hi @tbenice,

Sorry to hear about the issues. I imagine we can just unset the ACL option for the CreateBucket method, but how we handle createSubfolder will require a little more thought. Ideally we'd want to find out when the bucket was created and proceed from there, but for that we'll need to talk with the S3 team to see if we can pin down an exact date. I'll try to have a fix out for both of these issues soon.

[stof]

Given that the configuration of the bucket can still be changed, createSubfolder should probably choose its behavior based on the metadata of the bucket rather than choosing it based on the default value of the bucket creation at the time of creation of the bucket.

[stobrien89]

Apologies for the delay here. We decided to leave createSubfolder unaltered for backward compatibility reasons. Some users with buckets created prior to April 2023 might expect an ACL to be automatically determined and applied on their behalf. We considered the metadata route, but didn't want to make these abstractions any more expensive by adding additional S3 calls. We added a caveat to our mkDir() documentation here.

The new S3 access control paradigms are too fine-grained for us to reasonably translate into permissions levels, so it's unlikely there will be any additional work in that regard.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please open a new issue that references this one.